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Executive  Summary 

ASSESSMENT  OF  DoD  AND  INDUSTRY  NETWORKS 
FOR  COMPUTER  AIDED  LOGISTICS  SUPPORT  (CALS) 
TELECOMMUNICATIONS 


The  Department  of  Defense  is  committed  to  applying  the  best  in  modern 
technology  toward  improving  the  transfer  of  design,  engineering,  and  manufac¬ 
turing  technical  information  among  weapon  system  contractors  and  DoD 
organizations.  The  Military  Services,  the  Defense  Logistics  Agency  (DLA),  the 
Defense  Communications  Agency  (DCA),  and  industry  are  undertaking  or  planning 
telecommunications  support  for  such  transfer.  In  view  of  these  many  and  diverse 
efforts,  the  Computer  Aided  Logistics  Support  (CALS)  Steering  Group  through  the 
CALS  Conununications  Working  Group  has  recognized  the  need  for  evaluating 
them. 

We  have  undertaken  the  evaluation  and  conclude  that: 

•  While  CALS  data  transmission  requirements  have  not  yet  been  fully 
determined,  the  Defense  Data  Network  (DDN),  as  it  is  currently  configured, 
cannot  be  used  to  transmit  the  anticipated  high  volumes  of  weapon  systems 
engineering  drawings  and  technical  data. 

•  Because  telecommunications  standards  have  not  been  fully  developed,  it  is 
difficult  for  the  Services  to  undertake  policy  and  implementation  strategies 
for  transitioning  to  the  Open  Systems  Interconnection  (OSD  standards. 

•  While  there  are  intelligent  gateway  (IG)  technology  efforts  underway  to 
accommodate  CALS,  most  DoD  and  commercially  available  IGs  have  been 
designed  to  support  transmission  of  much  smaller  amounts  of  information 
than  are  usually  associated  with  engineering  drawings  and  technical 
documents.  In  addition,  an  IG  architecture  for  CALS  must  accommodate 
the  more  complex  translation  requirements  associated  with  graphics  and 
technical  data  that  are  not  fully  addressed  in  the  OSI  standards. 

We  recommend  that: 

•  The  Services  define  specific  data  storage  and  transmission  requirements 
and  determine  associated  data  volumes  and,  as  the  volumes  are  determined, 
inform  DCA  of  them  so  that  the  DDN  can  be  expanded  accordingly. 


•  A  phased  approach  be  taken  in  developing  and  implementing  the  OSI 
standards.  In  the  first  phase,  new  telecommunications  applications  within 
DoD  should  be  connected  to  the  DDN  using  the  DoD  message  routing 
standard.  National  Bureau  of  Standards  (NBS)  OSI  protocols  defined  for 
use  by  the  Government  should  be  implemented  as  products  become 
available.  Subsequent  phases  should  incorporate  International  Standards 
Organization  (ISO)  terminal  protocol  standards,  dynamic  routing  protocols, 
and  network  management  protocols. 

•  DoD  CALS  programs  include  funding  for  R&D  efforts  for  the  development  of 
IGs  because  IG  capabilities  will  be  needed  to  accommodate  translations 
between  dissimilar  procedures  and  practices  supporting  graphics  and 
technical  data  even  after  OSI  standards  are  implemented. 
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SECTION  1 


INTRODUCTION 


1.1  BACKGROUND 

The  Department  of  Defense  is  committed  to  applying  the  best  in  modern 
technology  toward  improving  the  transfer  of  technical  information  (engineering 
drawings,  bills  of  material,  etc.)  among  weapon  system  manufacturers,  contractors, 
DoD  organizations,  and  maintenance  activities.  The  Computer  Aided  Logistics 
Support  (CALS)  Steering  Group  was  established  to  foster  the  application  of  such 
technology,  to  improve  weapon  system  support  from  initial  design  to  operational 
logistics. 

The  CALS  Framework  document  states  the  basic  principles  and  concepts 
behind  the  CALS  program.  The  Phase  I  and  Phase  II  CALS  Core  Requirements  are 
being  developed  as  the  foundation  for  a  phased  approach  to  the  three  CALS  system 
architectures  developed  in  the  Framework. 

The  benefits  to  be  derived  from  Phase  I  and  Phase  11  activities,  as  developed  by 
the  D.  Appleton  Company  (DACOM),  are  summarized  in  Table  1-1.  The  information 
architecture  addresses  the  interdependent  functions  performed  by  individual  users. 
The  delivery  system  architecture  encompasses  computer  hardware  and  software, 
including  storage  and  processing  media,  as  well  as  technologies  of  communications, 
network  management,  data  management,  and  user  interface.  The  control 
architecture  ensures  that  the  total  application  area  is  effective  and  efficient  while 
both  user  requirements  and  computer  technologies  change  during  the  life  cycle  of  the 
weapon  system. 

In  today’s  high-technology  environment,  sharing  technical  information 
involves  telecommunications;  the  CALS  Communications  Working  Group  will 
therefore  assist  the  CALS  Steering  Group  in  the  areas  of  data  transmission 
requirements  and  communications  protocols.  The  Working  Group  is  concentrating 
on  communications  requirements  for  interfacing  with  industry  and  communicating 
CALS  data  within  DoD. 


TABLE  1-1 

THE  DoD  CALS  PHASED  MIGRATION  PLAN 


Architecture 


Today 


Benefits 


Mincmal  R&M 
Batch  LSAR 
Islands  in  logistic 
infrastructure 
Too  many  OIDs 
Out-of-date  technical 
manuals 

Limited  configuration 
control 

Slow  reprocurement  of 
spares 


•  Reduced  life-cycle  costs 

•  Improved  product  quality 

•  Shortened  leadtime 

•  Increased  availability 

•  Increased  competition 


Delivery  system  architecture 

•  Paper  exchange 

•  Increased  data  integrity 

•  Redundant  digitization 

•  Increased  data  accessi- 

•  n(n  -  1 )  record  transforms 

bility 

•  Mixed  media 

•  Increased  timeliness  of 

•  Inconsistent  geometric 

data 

models 

•  Lowered  paper  costs 

•  Lowered  paper-handling 

costs 

•  No  organized  concept  of 
an  integrated  data  system 


•  Reduced  cost  of  technical 
data 

•  Faster  response  to  new 
data  I'equirements 

•  Reduced  computer  and 
communications  costs 

•  Reduced  manpower  to 
build  Government  data 
systems 


Note:  RSM  =  reliability  and  maintainability,  LSAR  =  liigistiis  sup[iiirt  analysis  record, 
DIDS  =  Defense  integrated  Data  System 


The  responsibilities  of  the  Working  Group  include: 

•  Reviewing  and  assessing  CALS  telecommunications  requirements  and 
capabilities,  and  recommending  telecommunications  transition  strategies 

•  Reviewing  and  assessing  communications  aspects  of  DoD  Component  CALS 
plans,  including  telecommunications  protocols,  value-added  networks, 
internetting  with  non-Defense  Data  Network  (DDN)  networks,  and 
submitting  comments  and  recommendations  to  the  CALS  Steering  Group  as 
to  the  acceptability  of  these  plans 

•  Identifying  security,  survivability,  and  interoperability  requirements  for 
CALS  elements 

•  Advising  the  CALS  Steering  Group  about  the  availability  of  off-the-shelf 
products  supporting  required  telecommunications  standards 

•  Identifying  interface  requirements  to  DDN  and  other  Defense  Communica 
tions  Systems  supporting  CALS  elements 

•  Identifying  DoD  and  international  protocol  standards  that  should  be 
implemented  by  CALS  elements 

•  Providing  guidance  on  how  CALS  elements  should  identify  their 
requirements  to  the  Defense  Communications  Agency  (DCA)  to  ensure 
timely  telecommunications  support 

•  Maintaining  coordination  with  the  CALS  Specifications  and  Standards 
Working  Group  in  areas  related  to  telecommunications 

•  Maintaining  coordination  with  an  industry  focal  point  to  ensure  effective 
interchange  on  CALS- related  communications  initiatives. 

To  provide  the  Steering  Group  with  planning  guidance,  the  Working  Group 
must:  (1)  determine  the  most  effective  network  protocols  between  DoD  and  contrac 
tors,  (2)  determine  the  optimal  role  of  the  DDN  as  it  relates  to  CALS,  (3)  evaluate  the 
use  of  intelligent  gateway  (IG)  processors  for  CALS  to  ease  the  use  of  diverse 
hardware  and  software,  and  (4)  determine  the  role  of  telecommunications  standards 
in  CALS. 

1.2  OBJECTIVE 

All  the  Services,  the  Defense  Logistics  Agency  (DLA),  and  DCA  have  a  number 
of  efforts,  existing  and  planned,  to  provide  telecommunications  support  for  intra-  and 
inter-Service  communications.  In  addition,  a  number  of  initiatives  are  underway  to 
support  communications  over  telecommunications  media  between  the  Services  and 
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commercial  organizations.  In  view  of  these  ongoing  efforts,  the  Working  Group 
intends  to  propose  a  CALS  telecommunications  plan  or  architecture  that  would  best 
accommodate  both  existing  and  planned  efforts  in  DoD  and  industry  while  incor¬ 
porating  the  communications  protocol  standards  of  the  international  community. 

Transmission  of  engineering  drawings  and  technical  data  poses  unique 
requirements  in  terms  of  data  volume  and  protocol  standards  at  the  upper  layers. 
The  CALS  Specifications  and  Standards  Working  Group,  with  support  from  the 
National  Bureau  of  Standards  (NBS),  is  addressing  standards  for  such  data 
transfers.  The  CALS  Communications  Working  Group  is  concerned  with  the  pro¬ 
tocol  standards  proposed  for  Layers  I  through  5  of  the  Open  Systems  Interconnection 
(OSD  Seven  Layer  Model  and  the  types  of  communications  media  to  be  used  for 
transmitting  CALS  data.  Even  when  standards  are  adopted,  the  upper  layers  will 
continue  to  present  a  challenge  for  data  transmission.  Not  only  is  it  difficult  and 
time  consuming  to  identify  and  agree  to  use  a  specific  subset  of  a  standard  [e.g.,  a 
subset  of  the  Initial  Graphics  Exchange  Standard  (IGES)  for  vector  graphics],  but 
such  factors  as  cost  to  convert  or  translate  into  the  standard  may  be  unacceptable,  or 
the  final  product  may  not  yield  the  desired  results.  The  Communications  Working 
Group  is,  therefore,  also  addressing  the  use  of  IGs  to  ease  transmission  and 
conversion  of  CALS  data  at  the  upper  layers  (Layers  6  and  7). 

The  object  of  this  effort  is  to  identify  the  telecommunications  requirements  for 
CALS-related  efforts  in  the  Services  and  DLA  and  to  assess  Service  CALS  Imple¬ 
mentation  Plans  in  terms  of  local  and  long-haul  telecommunications  requirements. 
A  follow-on  task  will  develop  a  proposed  CALS  Telecommunications  Architecture, 
including  guidelines  for  transmitting  data  over  long-haul  lines,  recommendations 
for  making  optimal  use  of  the  DDN  and  alternative  means  of  data  transmittal,  and 
proposals  for  uses  of  IG  technology.  Other  considerations  to  be  addressed  include 
cost,  timeframes  for  implementation,  and  possible  effects  on  Service  and  DLA 
operations. 

We  have  evaluated  the  telecommunications  requirements  and  approaches 
within  the  Services  for  automating  and  modernizing  depositories  for  engineering 
drawings  and  technical  data,  as  well  as  the  direction  of  policy  for  planning  and 
implementation  of  Service-wide  telecommunications.  We  have  also  identified  and 
evaluated  commercial  state-of-the-art  communications  standards  and  networks. 


Section  2  discusses  CALS-related  telecommunications  requirements  within 
DoD.  Major  efforts  for  automating  repositories  for  engineering  drawings  and  techni¬ 
cal  data  are  discussed,  as  well  as  the  overall  direction  being  taken  within  each 
Service  for  telecommunications  support.  IG  efforts  are  discussed  in  terms  of  accom¬ 
plishments  to  date,  planned  implementation,  and  limitations  and  expectations  in 
terms  of  use  for  CALS-related  activities.  DCA’s  proposed  use  of  the  Defense 
Commercial  Telecommunications  Network  (DCTN)  as  a  backbone  to  provide  T1  and 
higher  speed  lines  is  also  addressed. 

Section  3  concentrates  on  the  status  of  various  commercial  protocol  and 
network  initiatives,  including  the  Manufacturing  Automation  Protocol  (MAP)  and 
the  Technical  and  Office  Protocol  (TOP),  the  Integrated  Services  Digital  Network 
(ISDN),  the  Fiber  Distribution  Data  Interface  (FDDI),  T-Carrier  Services,  and  NBS’ 
Government  Open  Systems  Interconnection  Profile  (GOSIP)  document.  These 
approaches  are  analyzed  and  compared  in  relation  to  the  OSI  Seven  Layer  Model. 

Section  4  assesses  the  status  of  CALS-related  telecommunications  and  presents 
conclusions  and  recommendations. 
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SECTION  2 


CALS  TELECOMMUNICATIONS  IN  DoD 

In  this  section  we  discuss  the  telecommunications  requirements  set  by  the 
Services  and  DLA  for  their  major  efforts  toward  modernizing  repositories  for 
engineering  drawings  and  technical  data.  Our  discussion  also  includes  their  plans 
and  developing  policies  for  telecommunications  support.  Where  IG  efforts,  both 
existing  and  planned,  are  appropriate  they  are  discussed.  We  begin  with  an 
overview  of  the  technology  in  place  and  planned  for  use  by  the  DDN  Program 
Management  Office  (PMO)  to  support  transmission  of  CALS  data.  Table  2-1  lists  the 
project  offices  visited.  Refer  to  the  glossary  for  definition  of  acronyms. 

The  definitions  of  protocols  to  be  used  within  any  of  the  Services  or  within 
individual  projects  may  be  in  flux.  Therefore,  any  differences  or  incompatibilities 
may  simply  indicate  that  work  is  still  being  done. 

2.1  DEFENSE  COMMUNICATIONS  AGENCY  TELECOMMUNICATIONS  EFFORTS 

2.1.1  Defense  Data  Network 

Since  most  of  the  CALS  umbrella  projects  have  specified  use  of  DDN  for  their 
long-haul  data  communications  needs,  we  reviewed  the  DDN  to  determine  its  appli 
cabiiity  as  a  transmission  medium  to  support  the  CALS  projects  data  transmission 
requirements.  Two  major  parts  of  DDN  were  investigated:  the  physical  subscriber 
access  links  and  backbone  network,  and  the  protocol  suite  that  provides  end-to-end 
connectivity. 

2.1. 1.1  Current  DDN  Environment 

The  DDN  is  a  DoD  common-user,  wide-area,  packet-switching  network  under 
the  control  and  management  of  DCA.  The  DDN  is  comprised  of  several  physically 
separate  subnets,  ranging  from  the  unclassified  Advanced  Research  Projects  Agency 
Network  (ARPANET)  to  the  top  secret  Sensitive  Compartmented  Information  Net 
work  (SCINET).  The  Military  Network  (MILNET)  segment  is  dedicated  to  unclassi 
fied  data  access. 


TABLE  2-1 


OFFICES  VISITED 


Project/office 

Location 

U.S.  Air  Force 

HQ  USAF  -  CALS  office 

Washington,  D  C. 

ATOS 

Wright-Patterson  AFB,  Ohio 

EDGARS 

Wright-Patterson  AFB,  Ohio 

IDS 

Wright-Patterson  AFB,  Ohio 

ASD/SIPX 

Wright-Patterson  AFB,  Ohio 

ULANA 

Washington,  D  C. 

U.S.  Navy 

NAVDAC  -  CALS  office 

Washington,  D  C. 

EDMICS 

Washington,  D.C. 

SPLICENET 

Washington,  D  C. 

SSN-21 

Washington,  D  C. 

TLRN 

Washington,  D.C. 

U.S.  Army 

HQ  Department  of  the  Army 

Washington,  D.C. 

DSREDS 

Huntsville,  Ala. 

HQAMC 

Alexandria,  Va. 

CECQM 

Fort  Monmouth,  N.J. 

Defense  Logistics  Agency 

HQ  DLA-Z/DCLSO 

Alexandria,  Va. 

DLA-ZW 

Alexandria,  Va. 

Defense  Communications  Agency 

HQ  DCA,  DDN  PMO 

McLean,  Va. 

The  DDN  backbone  is  homogeneous  in  its  transmission  services,  relying 
mainly  on  point-to-point  dedicated  lines  running  at  56  kilobits  per  second  (kbps).  In 
general,  these  lines  are  leased  from  American  Telephone  and  Telegraph’s  (AT&T’s) 

Dataphone  Digital  Service  (DDS).  Some  use  is  made  of  the  DCTN,  a  satellite-based 
network,  but  this  is  restricted  to  56  kbps  subrate  channels  and  is  used  for  non-  I 

CONUS  United  States  access.  Subscriber  access  links  (depicted  in  Figure  2  1),  J 

which  interface  the  user  to  a  packet-switching  node  (PSN),  range  from  relatively  ] 

slow  dial-up  links  to  dedicated  56  kbps  access  links.  Acquiring  a  56  kbps  line  now  | 

takes  between  18  and  24  months.  The  PSNs  are  C/30  computers  provided  by  Bolt,  \ 

i 

* 

I 

I 


Bisynchronous 

terminal 


Access  Controller,  OCA  =  Defense  Communications  Agency 


Beranek  and  Newman  (BBN)  Inc.  They  implement  a  dynamic,  adaptive  routing 
algorithm  to  route  packets  through  the  backbone  network.  The  C/30s  are  limited  to 
a  maximum  of  56  kbps  line  speeds.  Network  access  to  a  PSN  is  accomplished  via  the 
DoD-specified  implementation  of  the  Consultative  Committee  on  International 
Telephony  and  Telegraphy  (CCITT)  X.25  standard  interface  between  Data  Terminal 
Equipment  (DTE)  and  Data  Communication  Equipment  (DCE).  The  current 
protocol  suite  that  supports  end-to-end  or  host-to-host  connectivity  consists  of  the 
Internet  Protocol  (IP)  and  the  Transmission  Control  Protocol  (TCP).  The  IP  connects 
the  various  subnets  that  make  up  the  DDN.  TCP  provides  end-to-end  connectivity. 

Three  application-level  protocols  have  been  defined:  (1)  File  Transfer  Protocol 
(FTP),  which  performs  bulk  file  transfer;  (2)  Simple  Mail  Transfer  Protocol  (SMTP), 
which  supports  electronic  mail;  and  (3)  the  TELNET  protocol,  which  provides 
terminal  access  for  the  asynchronous,  scroll-mode  class  of  terminals.  FTP,  SMTP, 
and  TELNET  have  been  implemented  by  various  vendors  and  have  been  used  over 
DDN  for  several  years.  A  fourth  application  protocol  —  the  Display  Services 
Protocol  (DSP)  —  was  recently  approved  by  DCA.  It  will  provide  terminal  access  for 
synchronous,  block-mode  class  of  terminals.  The  current  Terminal  Access  Controller 
(TAG)  supports  asynchronous  terminals  only.  DSP  support  should  be  available  in 
18  months  within  the  new  mini-TAC.  The  mini-TAC  will  support  up  to  16  synchro¬ 
nous  or  asynchronous  terminals. 

Operator  control,  information  gathering,  and  fault  isolation  of  DDN  is 
accomplished  at  regional  monitoring  centers  operating  the  C/70  BBN  processor.  The 
individual  Services  fund  DDN  with  annual  contributions  that  cover  90  percent  of  its 
operational  expenses.  DCA  has  identified  subscriber  requirements  that  include 
connecting  7,000  host  processors  and  17,000  terminals  to  the  DDN. 

2. 1.1. 2  Planned  DDN  Environment 

The  relationship  of  the  DoD  Protocols  to  the  OSI  Model  is  illustrated  in 
Table  2-2.  DCA  plans  to  adopt  the  suite  of  OSI  protocols  as  they  become  accepted  by 
NBS.  The  GOSIP  document  should  supply  the  impetus  required  by  DCA  to  begin  the 
transition.  The  transition  should  start  in  1987  with  adoption  of  the  International 
Standards  Organization  (ISO)  Internet  Protocol  and  the  ISO  Transport  Protocol. 
The  OSI  lower  layers  for  long-haul  packet-switched  networks  is  the  same  as  those 
now  used  by  DDN,  i.e.,  the  X.25  DTE-to-DCE  interface.  This  similarity  allows  both 


to  connect  to  the  DDN.  To  achieve  connectivity  between  end  systems  that  are  within 
a  single  subnet  of  DDN,  not  requiring  a  gateway  passthrough,  requires  just  the  X.25 
connection. 


TABLE  2-2 

RELATIONSHIP  OF  THE  OSI  REFERENCE  MODEL 
TO  THE  DoD  PROTOCOLS 


OSI  layer 


Application 


Presentation 


Session 


Transport 


Network 


Data  Link 


Physical 


DoD  protocol  category 


Application  protocols 
(TELNET,  FTP,  SMTP  user  services) 


Host-to-host  protocols 
(IP  and  TCP) 


Network  access  control 
(X.25  and  ARPANET  Protocols,  such  as  1822) 


Note:  FTP  =  File  Transfer  Protocol:  IP  =  Internet  Protocol;  SMTP  =  Simple  Mail 
Transfer  Protocol:  TCP  =  Transmission  Control  Protocol 


To  achieve  connectivity  throughout  the  various  subnets  that  make  up  DDN  via 
a  gateway,  both  the  DDN  IP  and  the  ISO  Internet  Protocol  have  to  coexist  within  the 
DDN  internet.  The  coexistence  of  these  two  protocols  will  allow  end  host  systems  to 
communicate  over  the  DDN  using  either  the  OSI  upper  layer  protocols  [e.g., 
Transport  Protocol  Class  4  (TP  4)  and  File  Transfer,  Access,  and  Management 
(FTAM)]  or  the  DoD  protocol  suite  (e.g.,  TCP,  FTP).  The  DDN  will  thus  be  comprised 
of  two  closed  communities  —  one  for  ISO  host-to-host  and  one  for  DDN  host  to- 
host  —  using  the  DDN  backbone  as  the  transmission  medium.  In  the  transition 
period  until  full  acceptance  and  implementation  of  the  ISO/OSI  protocol  suite, 
parallel  operation  of  the  two  closed  communities  is  required.  This  approach  could  be 
greatly  enhanced  by  the  use  of  protocol  gateways  that  would  allow  interoperability 
between  the  two  closed  communities.  NBS  is  developing  such  a  protocol  gateway. 


DC  A  plans  to  upgrade  the  physical  transmission  medium  used  in  the  backbone 
network.  The  changes  involve  use  of  a  new  PSN,  called  the  C/300,  and  Tl 
[1.544  megabits-per-second  (Mbps)]  channels.  DCA  now  expects  the  Tl  capability  in 
5  years.  The  classified  subnets  will  be  fully  integrated  into  DDN  when  BLACKER 
technology  is  implemented  (in  1988  —  1989).  BLACKER  technology  will  provide  a 
multilevel,  host-to-host  security  system  for  DDN  and  allow  for  the  sharing  of 
backbone  trunks  and  other  resources.  Once  the  BLACKER  technology  is  fully 
implemented,  the  DDN  will  be  divided  between  an  unclassified  segment,  MILNET, 
and  a  classified  segment,  the  Defense  Integrated  Secure  Network  (DISNET). 
BLACKER  technology  will  require  use  of  the  TCP/IP  protocols.  The  MILNET 
unclassified  segment  will  use  the  KG-84  encryption  devices  on  the  subscriber  access 
links  and  backbone  trunks.  DCA  also  plans  to  implement  a  usage  charge-back 
method  that  will  be  based  on  kilopackets  sent  over  DDN.  The  DDN  tariffs  for  cost 
recovery  that  are  to  go  into  effect  in  FY90  are  listed  in  Table  2-3. 


TABLE  2  3 
DDN  TARIFFS 


Charges 

Cost 

Monthly  charges 

Host-56  kbps-smgle  home 

$4,000  00 

Host-56  kbps-dual  home 

$6,500  00 

Host-9  6  kbps-smgle  home 

$1,750  00 

Host-9  6  kbps-dual  home 

$2,700  00 

Hourly  dial-tn  charge 

$  4  50 

Kilopacket  charges 

Peak  time  usage 

$  1  25 

Off  peak  time  usage 

$  0  60 

Precedence  2 

$  2  00 

Precedence  3 

$  3  00 

Precedence  4 

$  4  00 

The  kilopacket  charge  will  be  based  on  packets  of  any  size;  the  maximum 
packet  size  of  1, 024, ()()()  octets  or  bytes  should  therefore  be  used.  To  take  advantage 
of  the  substantial  reduction  in  cost,  off-peak  time  use  of  DDN  is  also  recommended 


for  transmission  of  non-time-critical  data.  The  costs  of  DDN  are  expected  to  be 
competitive  with  commercial  packet  networks. 

2.1. 1.3  CALS  Use  of  DDN 

Use  of  DDN  by  the  various  CALS  projects  would  create  a  significant  problem 
within  the  network.  The  problem  stems  from  the  physical  transmission  bandwidth 
(56  kbps)  provided  by  DDN.  Graphical  data,  even  in  a  greatly  compressed  state, 
requires  millions  of  bits.  The  anticipated  workload  of  just  one  CALS  project,  the 
Army  Digital  Storage  and  Retrieval  Engineering  Data  System  (DSREDS)  at 
Picatinny  Arsenal,  would  saturate  the  entire  DDN  with  its  daily  volume  of  inter-site 
data  transmissions.  The  anticipated  daily  load  between  Picatinny  Arsenal  and  Rock 
Island  ’^rsenal  is  12  gigabytes.  Dividing  by  20  for  an  average  compression  ratio  of 
20:1  results  in  a  total  of  600  megabytes  of  graphics  information  to  be  transmitted 
between  the  two  locations.  At  56  kbps  or  7,000  bytes  per  second,  the  DDN  can  trans 
mit  25.2  megabytes  an  hour.  Dividing  600  megabytes  by  25.2  megabytes  equals 
23.8  hours  of  transmission  time.  This  assumes  a  dedicated  medium  that  is  overhead- 
free.  Add  to  this  the  estimated  overhead  of  25  percent  imposed  by  the  various 
protocols  and  acknowledgments  within  DDN,  and  the  time  to  transmit  approaches 
30  hours. 

Note  that  what  is  being  discussed  is  the  workload  from  just  one  project.  It  does 
not  include  text  transfer  requirements.  Add  to  this  the  transmission  workloads  of 
other  CALS  projects  and  DDN’s  existing  users,  and  the  magnitude  of  the  problem 
becomes  clear.  The  bandwidth  provided  by  DDN  (56  kbps),  with  an  estimated 
overhead  of  20  to  30  percent,  is  not  sufficient  to  handle  the  estimated  CALS 
workload. 

The  cost  of  DDN  should  also  be  considered.  On  the  basis  of  kilopacket  charges 
scheduled  to  start  in  1990,  the  cost  of  transferring  600  megabytes  of  graphics  (the 
daily  compressed  load  anticipated  for  Picatinny  Arsenal)  would  be  approximately 
$725.  This  assumes  a  worst  case  of  60  percent  prime-time  transmission  and 
40  percent  off-peak  time  to  accommodate  the  30  hours  computed  above. 

Although  the  DDN  cannot  now  accommodate  the  data  required  for  trans 
mission  by  CALS  projects,  it  can  provide  some  CALS  support.  The  present  DDN  can 
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be  used  to  order  drawings  from  connected  organizations  or  obtain  status  information 
regarding  a  drawing  or  technical  order. 

Before  connection  to  the  DDN,  DCA  will  analyze  the  transmission  require 
ments  of  individual  activities.  The  results  of  these  studies  are  called  Functional 
Requirements  and  Interface  Documents  (FRIDs).  These  FRIDs  are  used  to  evaluate 
transmission  requirements  and  recommend  specific  courses  of  action  with  regard  to 
connection  to  the  DDN.  Every  prospective  CALS  project  should  request  such  a  study 
by  DCA.  The  CALS  projects  should  also  inform  DCA  of  their  anticipated 
transmission  volumes,  to  document  the  need  for  increased  transmission  bandwidth. 
DCA  publishes  a  list  of  exemptions  from  the  mandate  that  dictates  use  of  DDN  by  all 
DoD  activities.  One  such  exemption  applies  to  the  requirement  to  interface  with  a 
non-DoD  host  that  is  shared  by  several  CALS  projects.  This  exemption  could  justify 
a  dedicated  point-to-point  connection  to  a  manufacturer’s  computer  system. 


2.1.2  Defense  Commercial  Telecommunications  Network 

The  DCTN  is  a  satellite-based  network  that  is  used  primarily  for  voice  and 
video.  DCA  is  the  program  manager  for  DCTN,  which  has  been  operational  since 
February  1986.  The  DCTN  is  essentially  a  service  that  will  prr  ide  many  major 
military  locations  with  T1  transmission  speeds.  It  is  built  of  basic  AT&T  digital 
components  consisting  of  a  Digital  Access  Cross-Connect  System  frame  and  a  No.  5 
Electronic  Switching  System  (5ESS).  The  service  provides  support  for  both 
dedicated  and  switched  facilities,  and  can  be  reconfigured  dynamically  from  a  net¬ 
work  control  center.  All  transmissions  and  switching  are  digital.  At  present,  DCTN 
is  made  up  of  satellite  and  15  terrestrial  nodes,  9  of  which  are  collocated  with  earth 
stations  that  support  satellite  transmission  and  reception.  The  remaining  six  nodes 
are  linked  to  the  earth  station  sites  by  terrestrial  T1  links.  DCTN  terrestrial  links 
support  switched  voice,  dedicated  voice  and  data,  and  video  conferencing.  The 
bandwidth  is  now  divided  into  24  voice  channels  of  56  kbps  each,  in  the  typical  T1 
manner.  Dynamic  allocation  of  bandwidth  is  being  used  to  support  video 
conferencing. 

2. 1.2. 1  Satellite  Based  Networks 

Some  general  properties  of  satellite  networks  are  relevant  to  CALS  telecom 


munications  requirements.  A  satellite  in  geosynchronous  orbit  is  visible  to  about 
one-quarter  of  the  earth’s  surface,  and  transmission  costs  are  independent  of  the 


distance  within  the  satellite’s  area  of  coverage.  Both  broadcast  and  point  to-point 
applications  are  possible.  The  earth-to-satellite-to-earth  round  trip  imposes  a 
propagation  delay  of  about  one  quarter-second  on  transmissions.  Satellites  operate 
in  the  4  to  6  gigahertz  (GHz)  range  and  provide  approximately  500  megahertz  (MHz) 
of  bandwidth.  This  500  MHz  of  bandwidth  is  divided  into  12  subchannels  of  40  MHz 
each,  using  frequency  division  multiplexing  (FDM).  The  usable  bandwidth  of  each  of 
these  subchannels  becomes  36  MHz  after  a  4  MHz  guard  band  is  extracted  to  prevent 
interference.  This  36  MHz  of  bandwidth  can  be  further  divided  by  use  of  either  FDM 
or  time  division  multiplexing  (TDM).  With  FDM,  the  subchannel  can  be  divided  into 
1,200  voice  circuits.  Use  of  TDM  could  provide  varying  bandwidths  over  the  36  MHz 
channel.  Typical  divisions  are:  one  50  Mbps  channel,  sixteen  T1  channels, 
four  hundred  64  kbps  channels,  or  six  hundred  40  kbps  channels. 

2.1. 2.2  CALS  Use  of  DCTN 

DCA  is  developing  plans  to  expand  DCTN.  As  more  information  about  DCTN 
is  obtained,  it  will  be  disseminated  among  CALS  participants.  This  technology  and 
service  may  be  able  to  provide  the  high-bandwidth  service  required  by  the  CALS 
projects. 

2.2  NAVY  TELECOMMUNICATIONS  REQUIREMENTS 

The  Navy  Standard  Data  Communications  Architecture  now  under  develop¬ 
ment  addresses  the  Navy’s  plans  to  transition  from  the  DoD  protocol  suite  to  the  OSI 
standards.  Two  projects  present  somewhat  different  requirements  for  storage, 
retrieval,  and  transmission  of  engineering  drawings  —  the  Navy  Engineering 
Drawing  Management  Information  and  Control  System  (EDMICS)  and  the  SSN-21 
Advanced  Attack  Submarine  Project.  Two  examples  of  approaches  to  the 
development  and  implementation  of  IGs  are  the  Stock  Point  Logistics  Integrated 
Communications  Environment  (SPLICE),  which  accommodates  gateway  processing 
at  all  seven  layers  of  the  OSI  Model,  and  the  Technical  Logistics  Reference  Network 
(TLRN),  which  has  a  simpler  approach  and  handles  gateway  functions  at  the  upper 
layers  only. 

2.2.1  Navy  Standard  Data  Communications  Architecture 

The  Navy  Data  Automation  Command  (NAVDAC),  the  Navy  'I’elecom 
munications  Command  (NAVTELCOM),  and  designated  System  Command 
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representatives  are  reviewing  major  computer  networking  efforts  with  plans  to 
publish,  as  a  joint  effort,  a  compendium  of  protocols  that  would  have  to  be  supported 
to  implement  CALS  technology.  Such  a  review  will  provide  insight  into  the  extent  to 
which  translators  will  have  to  be  developed  for  widespread  data  exchange. 

NAVDAC  is  also  developing  a  draft  standard  data  communications 
architecture  for  Navy- wide  implementation.  The  document  is  not  yet  available  for 
distribution.  It  is  to  provide  specific  guidance,  as  available,  for  procurement  and 
development  of  interoperable  data  communications  support.  All  shore-based 
information  systems  are  expected  to  meet  this  standard.  Of  course,  some  tactical 
situations  will  require  deviations  from  the  architecture.  These  deviations  will  be 
closely  monitored  and  managed  by  the  Space  and  Naval  Warfare  Systems  Command 
(SPAWAR). 

The  international  protocol  suite  —  not  the  DoD  suite  —  was  chosen  as  the  basis 
for  development  of  the  Navy  standards.  Although  DoD  protocols  are  more  widely 
implemented  now  than  international  standards,  international  protocols  are  expected 
to  overtake  the  DoD  protocols  in  availability  by  1988.  Therefore,  use  of 
international  standards  is  mandatory  for  systems  targeted  for  implementation  in 
1988  and  beyond.  Extensive  system  modifications  will  be  required  to  implement 
interaction  of  Navy  application  environments.  Systems  implemented  with  DDN 
protocols  will  have  to  be  changed  again  within  2  years.  Navy  guidance,  therefore, 
encourages  use  of  international  standards  for  new  developments  unless  there  is  a 
compelling  requirement  for  interoperability  with  an  existing  system  using  DoD 
protocols  before  1988.  This  does  not  preclude  use  of  other  protocols  in  situations 
where  interoperability  is  not  needed. 

Systems  and  networks  are  to  be  implemented  with  a  single  suite,  either  Navy 
standard  or  DoD.  Intermixing  of  protocols  will  not  be  approved.  In  the  meantime, 
the  following  is  recommended: 

•  For  proprietary  vendor  implementations,  push  for  international  protocol 
suites  in  the  vendor  line.  Minimize'  development  of  systems  and  capabilities 
that  extend  dependence  on  vendor-unique  products  [e.g..  System  Network 
Architecture  (SNA)].  Use  DDN  electronic  mail  hosts  rather  than  specific 
vendor  system  constraints  and  formats. 
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•  For  those  connected  to  DDN  using  X.25  protocols,  X.25  is  common  to  both 
suites  and  will  not  require  any  retrofitting.  Continue  using  DDN  with  X.25 
and  also  do  above. 

•  For  those  connected  to  DDN  with  full  DoD  protocol  support,  continue  using 
the  DoD  suite.  Plan  on  using  the  NBS/DoD-provided  gateway  to  interact 
with  Navy  standard  systems  and  look  for  an  opportunity  to  transition  from 
the  DoD  suite. 

•  For  those  already  implementing  the  Navy  standard  environment,  connect 
to  DDN  using  X.25  and  request  a  waiver  from  DoD  protocol  implementation 
via  NAVDAC. 

Figure  2-2  displays  the  set  of  standards  and  protocol  suites  designed  to  ensure 
interoperability  of  Navy  information  systems.  The  suite  is  composed  of 
international  standard  protocols,  augmented  as  necessary  by  proposed  protocol 
efforts  and  Navy  standards.  These  standards  and  the  subsets  to  be  included  in  the 
Navy  standard  are  described  in  detail  in  Appendix  A. 

Use  of  record  level  interaction  (Transport)  with  Common  Application  Service 
Elements  (CASE)  and  Navy  Standard  Addressing  is  expected  to  significantly 
enhance  implementation  and  operation  of  the  standard  Navy  system.  Applications- 
level  security  and  standard  graphics  problems  are  still  outstanding.  The  Navy 
indicates  that  FTAM  satisfies  Navy  requirements  completely.  Performance  has  not 
been  adequately  measured,  but  experience  suggests  that  additional  performance 
options  may  be  desirable.  These,  however,  are  low-priority  concerns  at  this  point. 
TOP,  which  incorporates  X.400  (Message  Handling  Protocol),  and  Navy  Standard 
Addressing  will  satisfy  Navy  requirements  today.  DoD  SMTP  is  a  suitable 
substitute  for  separate  electronic  mail  hosts. 

Additional  protocol  requirements  not  yet  addressed  in  the  proposed  Navy 
standards  include: 

•  Ship-to-Shore  Protocols 

•  Network  Management  Protocols 

•  Network  Security  Protocols 

•  ISDN 

•  Video  Teleconferencing. 
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Note:  FTAM  =  File  Transfer,  Access,  and  Management.  VTP  s  Virtual 
Terminal  Protocol.  CASE  =  Common  Application  Service  Elements. 
PLP  »  Packet  Level  Protocol;  TP  =  Transport  Protocol.  TP-4  =  Transport 
Protocol  Class  4.  TP-0  *  Transport  Protocol  Class  0;  TP-2  =  Transport 
Protocol  Class  2;  EGP  »  Exterior  Gateway  Protocol:  HGP  »  Host-to-Gateway 
Protocol;  ICMP  a  Internet  Control  Message  Protocol;  IP  »  internet 
Protocol;  FOOl  »  Fiber  Distribution  Data  Interface.  ISDN  =  Integrated 
Services  Digital  Network 

FIG.  2-2.  PROPOSED  ARCHITECTURE  FOR  NAVY 
PROTOCOL  SUITES 


The  Navy  will  be  undergoing  a  complex,  continuing  transition  in  data 
communications  support  for  the  next  5  to  10  years.  Navy  protocol  implementation 
estimates  are: 

•  Vendor  implementations  only  (80  percent  plus). 

•  Vendor  implementations  with  connections  to  DDN  using  X.25  for  long-haul 
circuit  consolidation  (most  systems  —  15  percent). 

•  Use  of  DoD  protocol  suite  in  applications  programs  and  connection  to  DDN 
(labs  only  —  5  percent). 

•  Use  of  international  protocols.  The  Navy  standard  protocol  suite  is  imple 
mented  at  NBS,  NAVDAC,  and  the  Navy  Regional  Data  Center  ( NARDAC) 
Washington  to  demonstrate  interaction  (less  than  1  percent). 


In  summary,  the  Navy  operational  support  is  primarily  vendor-specific,  with 
minimal  use  of  DoD  protocols. 

NAVDAC  Newport  has  obtained  structured  protocol  tests  from  NBS  and  DCA 
for  international  and  DoD  standard  protocols  and  has  acquired  hardware  to  run 
these  tests  for  Navy  hardware  suites,  software  suites,  or  both.  This  capability  is 
available  for  use  by  Navy  activities  to  demonstrate  product  compatibility  during 
procurement  or  after  major  upgrades  of  vendor  software.  The  Navy  has  offered  to 
allow  connections  of  vendor  equipment  via  the  OSI  Network  (OSINET)  at  NBS  for 
testing  off-the-shelf  products  for  compatibility  with  Navy  standards  early  in  the 
vendor  design  process.  These  measures  are  intended  to  maximize  the  use  of  off-the- 
shelf  equipment  to  satisfy  Navy  requirements. 

2.2.2  Navy  Engineering  Drawing  Modernization  Efforts 

The  Nauy  Engineering  Drawing  Management  Information  and  Control  System 
(EDMICS)  project  is  a  joint  Navy/Marine  Corps/DLA  initiative  to  provide  some 
40  engineering  data/drawing  repositories  with  a  state-of-the-art  management 
system.  The  goal  of  EDMICS  is  to  provide  users  with  accurate  and  timely  drawing 
index  and  image  information  on  all  Navy  equipment  and  weapon  systems. 
Installation  of  EDMICS  at  engineering  drawing  repositories,  Naval  shipyards. 
Naval  air  rework  facilities  (NARFs),  and  electronic  centers  throughout  the  United 
States  is  to  begin  in  the  first  quarter  of  FY88.  A  prototype  EDMICS  system  for 
evaluation  of  advanced  technology  components  and  peripheral  products  has  been 
installed  at  the  Naval  Air  Technical  Services  Facility,  Philadelphia.  Pa. 

Engineering  drawing  index  and  image  information  will  be  transmitted  locally 
(intrasite)  and  long  distance  (intersite).  Figure  2  3  illustrates  the  EDMICS  data 
communications  configuration. 

Intrasite  communications  will  depend  on  local  area  networks  (  LAN's).  For  sites 
with  existing  LANs  that  meet  EDMICS  throughput  and  capacity  requirements,  the 
existing  LAN  will  be  used  for  intrasite  communications.  At  other  sites,  a  LAN  will 
be  acquired  and  installed  as  part  of  the  EDMICS  installation.  The  LANs  acquired  as 
part  of  the  EDMICS  cf)ntract  will  be  a  baseband  LAN  with  coaxial  cabling,  providing 
for  a  minimum  communications  speed  of  1.54  Mbps.  Each  LAN  will  he  able  to 
support  up  to  250  graphics  and  video  display  workstations.  Users  will  be  able  to 
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query  the  index  database  and  request  individual  drawing  or  drawing  package 
reproductions  in  a  variety  of  output  media. 

Intersite  communications  will  be  achieved  through  the  DDN.  Access  to  the 
DDN  will  be  via  SPLICE  Tandems,  which  will  be  collocated  at  all  EDMICS  sites  and 
act  as  an  interface  to  the  DDN.  Users  at  one  EDMICS  site  will  be  able  to  query  the 
EDMICS  index  database  at  another  site  and  request  drawings  on-line. 

Because  of  the  large  size  of  drawings  image  files  (8  megabytes  or  more)  and  the 
current  maximum  speed  of  the  DDN  (56  kbps),  the  exchange  of  image  information 
over  the  DDN  will  not  be  convenient  or  efficient  for  users.  Most  image  transmission 
between  sites  is  expected  to  take  place  by  postal  or  courier  service,  using  optical  disk, 
magnetic  tape,  aperture  card,  or  hard  copy  depending  on  the  volume.  This  means  of 
communication  will  probably  prove  to  be  the  most  efficient  one  in  terms  of  the  costs 
of  sending  large  quantities  of  drawings.  The  DDN  is  the  most  cost-effective  means 
available  to  perform  on-line  data  query  and  request  functions.  The  DDN  may  also  be 
used  to  perform  priority  image  transfers  for  small  numbers  of  images.  Leased, 
dedicated,  high-speed  lines  are  one  of  the  few  means  available  for  long-distance,  on¬ 
line  transfer  of  drawing  images.  But  using  leased  lines  costs  far  too  much  to  merit 
application  in  EDMICS.  When  the  speed  and  capacity  of  the  DDN  increase  to  such  a 
level  as  to  make  long-distance  telecommunications  efficient  and  cost-effective,  the 
DDN  can  be  used  for  on-line  image  transmission. 

Appendix  B  lists  the  data  communication  volume  requirements  for  each  of  the 
8  primary  repositories,  8  shipyards,  6NARFs,  4  Naval  Electronics  Systems  Engi 
neering  Centers  (NESECs),  and  10  other  secondary  repositories.  At  the  large 
repositories,  the  system  is  expected  to  process  5,000  or  more  drawing-index  queries 
and  image  requests  a  day  from  as  many  as  250  on-line  users.  Of  these, 
approximately  3,400  are  expected  to  be  from  local  on-line  users,  and  1,600  from 
remote  users  via  the  SPLICE  interface.  An  estimated  50  percent  of  image  requests 
will  be  for  image  viewing  on  a  graphics  display.  At  first,  authorized  remote  users 
will  initially  request  and  view  100  or  fewer  drawing  images  a  week. 

Standards  proposed  for  use  as  part  of  the  EDMICS  include: 

•  Initial  Graphics  Exchange  Standard  (IGES),  Version  2.0  and  all  subsequent 
versions 


•  Product  Definition  Exchange  Specification  (PDES),  Version  1.0  format  and 
all  subsequent  versions 

•  CCITT  Group  4  Recommendations  for  drawing  image  data  compression, 
CCITT  Recommendation  T.6  "Facsimile  Coding  Schemes  and  Coding 
Control  Functions  for  Group  4  Facsimile  Apparatus”,  and  all  "T”  Series 
Recommendations  from  the  CCITT  "Red  Book”  Volume  VII,  "Terminal 
Equipment  and  Protocols  for  Telematic  Services” 

•  Standard  Generalized  Markup  Language  (SGML) 

•  TCP/IP 

•  CCITT  Recommendation  X.25 

•  Institute  of  Electrical  and  Electronic  Engineers  (IEEE)  Standard  802  for 
LAN  Implementation 

•  Navy  Data  Automation  Technical  Standard  17. 8A,  "Navy  Data  Network 
Connection  Standard.” 

The  SSN-21  Baseline  CALS  Project  will  demonstrate  elements  of  an  end-to-end 
computer-aided  logistics  support  concept,  integrated  with  the  planning  and  detailed 
design  phase  of  a  major  acquisition  program,  the  SSN-21  Advanced  Attack 
Submarine.  During  demonstration  planning  and  execution,  the  working  group  will 
emphasize  categories  of  data  to  be  transferred  between  the  Navy  and  contractor 
organizations,  including  nonprocessable  text  and  graphics;  processable  data,  such  as 
bills  of  material;  engineering  drawings  and  illustrations;  and  other  aspects  of  a 
digital  product  model  representing  the  ship  and  its  major  systems/subsystems. 
Other  areas  of  concern  to  be  addressed  include  use  of  text  and  graphics  standards  for 
digital  data  interchange;  data  validation  and  security;  integration  of  selected 
reliability,  maintainability,  and  testability  analysis  tools  with  evolving  computer- 
aided  design  (CAD)  database  development;  use  of  an  on-line  integrated  database  of 
logistics  support  analysis  (LSA)  information;  and  generation  of  technical 
documentation,  using  as  a  starting  point  selected  data  sets  stored  within  the 
CALS/ILS  (integrated  logistics  support)  data  repository. 

There  are  no  current  plans  for  direct  communication  lines  with  contractors  or 
transmission  of  the  information  between  shipyards  over  long-haul  lines.  Data 
transfer  for  design  and  construction  of  the  SSN-21  class  of  ships  is  handled  via 
magnetic  tape,  since  most  of  the  data  is  classified.  There  is  a  need  for  ability  to 
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access  the  systems  directly,  but  funding  constraints  and  the  unavailability  of  the 
needed  technology  do  not  make  such  access  feasible  for  the  near  term. 

One  of  the  major  problems  to  overcome  is  the  fact  that  two  shipyards  (the 
Electronic  Boat  Division  of  General  Dynamics  and  the  Newport  News  Shipyard) 
have  responsibility  for  the  design  of  separate  but  interrelated  components  of  the 
submarine.  The  design  is  being  handled  by  two  contractors  using  different  CAD 
systems.  General  Dynamics  uses  Computer  Vision;  the  Newport  News  shipyard  uses 
CADAM.  Both  Computer  Vision  and  CADAM  have  developed  pre-  and  post¬ 
translators  into  IGES,  but  much  work  still  needs  to  be  done  for  an  effective 
translation.  There  will  never  be  a  100  percent  translation  capability.  The  process  of 
cleaning  up  a  complex  drawing  with  manual  intervention  has  been  reduced  to 
3  to  4  hours.  The  SSN-21  Project  supports  approximately  300,000  to  400,000 
drawings  between  the  two  shipyards.  Additional  drawings  are  received  in  hard  copy 
from  other  vendors  for  various  components  of  the  submarine.  The  Program  Office 
intends  to  develop  a  quality  assurance  process  for  translation. 

Another  problem  is  the  fact  that,  despite  agreement  on  standards,  different 
procedures  and  practices  (engineering  models)  are  used  in  the  design  process  at  the 
two  shipyards.  As  a  result,  different  pictures  are  displayed  on  the  two  systems  for 
the  same  data  represented  in  the  same  IGES  subset.  Other  system  differences 
include  the  fact  that  in  some  cases  there  is  simply  no  representation  in  one  system 
for  elements  represented  in  the  other.  There  is  a  need  to  develop  standards  for 
procedures  and  practices  for  the  design  of  Navy  systems.  Again,  other  priorities  and 
funding  constraints  make  it  difficult  to  address  standardization  of  procedures  at  this 
time.  However,  the  SSN-21  Program  Office  is  committed  to  the  development  of 
standards,  and  this  has  been  impressed  upon  both  shipyards. 

2.2.3  Intelligent  Gateway  Projects 

The  primary  objective  of  the  Stock  Point  Logistics  Integrated  Communications 
Environment  (SPLICE)  is  to  provide  Navy  and  other  DoD  customers  with  responsive 
and  economical  Uniform  Automated  Data  Processing  System  —  Stock  Points 
(UADPS-SP)  support  by  using  a  standard  minicomputer  hardware  and  software 
suite  for  telecommunications,  interactive  processing,  front-end  processing,  and 
terminal  concentrator  requirements. 
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The  SPLICE  Network  (SPLICENET),  as  depicted  in  Figure  2  4,  serves  three 
purposes.  First,  it  replaces  front-end  and  terminal  concentrator  processors  in  the 
UADPS-Burroughs  environments.  Second,  it  replaces  various  stand-alone 
minicomputer  suites,  which  support  a  number  of  projects,  with  a  standard 
minicomputer  environment  that  will  also  support  UADPS  functions  and  new 
automated  information  systems  such  as  the  Automation  of  Procurement  and 
Accounting  Data  Entry  (APADE)  System.  Third,  it  provides,  through  DDN, 
teleprocessing  connectivity  for  the  inventory  control  points  (ICPs),  stock  points,  and 
specific  users  of  logistics  information.  SPLICE  uses  Tandem  linearly  expandable, 
fault-tolerant  technology  and  will  operate  at  62  regional  sites,  including  ICPs,  stock 
points.  Naval  reserve  readiness  commands  (NRRCs),  and  NARDACs.  Tandem's 
commercially  available  protocols  include  an  interface  to  X.25  networks,  a 
proprietary  set  of  Layer  3  through  5  protocols  called  EXPAND,  and  a  Tandem  file 
transfer  protocol  and  mail  protocol. 

It  is  Tandem’s  intention  to  allow  different  synchronous  terminals  from 
different  vendors  to  communicate  with  application  programs  within  a  Tandem 
computer.  Tandem  has  its  own  synchronous  protocol  for  its  terminals  (this  protocol 
is  called  the  6530).  In  addition.  Tandem  plans  to  allow  synchronous  terminals  from 
different  vendors  that  are  connected  locally  to  a  Tandem  to  communicate  across  a 
packet-switched  network  to  an  application  program  in  another  Tandem  computer. 
Currently,  Tandem  has  developed  these  interfaces  for  International  Business 
Machines  (IBM)  Corporation  compatible  synchronous  terminals  (2780/3780/327X), 
and  the  Federal  Data  Corporation  (FDC)  has  developed  the  interfaces  for  Burroughs 
look-alike  asynchronous  and  synchronous  terminals.  Basically,  this  means  that  the 
IBM  and  Burroughs  protocols  are  translated  into  the  Tandem  synchronous  protocols 
(6530  protocol).  The  6530  protocol  is  then  used  to  communicate  with  application 
programs,  either  in  a  local  Tandem  host  or  in  a  Tandem  computer  that  is  connected 
by  a  communications  network. 

Tandem  currently  provides  file  transfer  capabilities  between  Tandem  and 
other  vendor  computers,  such  as  IBM,  UNIVAC,  and  Honeywell.  The  Navy  has 
developed  file  transfer  capabilities  between  Tandem  and  Burroughs.  These  file 
transfers  are  for  flat  sequential  files  only,  and  do  not  apply  to  indexed  files. 
SPLICENET  also  supports  security,  automatic  routing,  network  management  and 


control,  and  gateway  functions  for  IBM  SNA  and  IBM  bisynchronous  hosts  that 
enable  users  in  the  ICPs,  the  stock  points,  and  DLA  to  communicate  with  each  other. 

The  Naval  Supply  Systems  Command  (NAVSUP)  has  two  requirements  for 
interoperability  —  one  within  the  Navy  Stock  Point  environment  for  communication 
between  Tandem  nodes  in  the  SPLICENET  community,  the  other  for  interoperable 
communications  outside  the  SPLICENET  community. 

NAVSUP  plans  to  use  the  X.25  interface  to  DDN  and  the  Tandem  EXPAND 
protocols  to  communicate  among  SPLICE  sites.  Communications  between  a  SPLICE 
site  and  other  non-SPLICE  DoD  sites  will  be  conducted  by  the  X.25  access  to  DDN 
through  a  front-end  processor  or  outboard  controller  that  implements  TCP/IP  and 
TELNET  separate  from  the  Tandem  to  provide  end-to-end  transport  of  the  data 
across  the  DDN.  Therefore,  within  the  Tandem  host  there  will  be  two  sets  of 
protocols  —  one  based  on  the  Tandem  vendor-specific  suite,  the  other  on  the  DoD 
suite. 

The  Technical  Logistics  Reference  Network  (TLRN)  is  an  information  service 
that  has  evolved  over  the  past  10  years  through  testing  and  use  within  the 
Department  of  the  Navy,  specifically  the  Naval  Sea  Systems  Command  (NAVSEA) 
and  the  Naval  Air  Command  (NAVAIR).  This  service  is  designed  to  improve  the 
visibility  and  usefulness  of  material  information  supporting  the  phases  of  the 
military  hardware  life  cycle,  from  system  design  to  acquisition,  through 
maintenance  and  refurbishment,  to  final  phaseout. 

Users  at  all  Navy  shipyards  currently  have  terminal  access  directly  to  the 
TLRN  host  to  use  the  Federal  Supply  Catalog  database  resident  on  the  central  host. 
The  TLRN  will  also  enable  a  user  at  a  shipyard  to  do  the  following  by  terminal; 

•  Access  the  local  shipyard  information  system 

•  Link  into  DLANET  (DLA  Network)  to  access  the  Standard  Automated 
Material  Management  System  (SAMMS) 

•  Access  other  shipyard  management  information  systems  directly 

•  Access  other  host  machines  connected  to  the  TLRN,  including  the  central 
TLRN  host. 

Access  to  these  systems  will  be  provided  through  a  Tandem  gateway.  I'sers 
will  interface  to  the  Tandem  with  currently  available  "on  station"  hardware,  such  as 


microcomputers,  dumb  terminals,  and  printers.  At  first,  the  TLRN  supported 
asynchronous  terminals  only;  now  it  supports  some  synchronous  terminals  as  well. 
The  programs,  developed  by  Innovative  Technology  Inc.,  can  be  used  on  any 
asynchronous  intelligent  terminal  supporting  Microsoft  Disk  Operating  System 
(MS  DOS)  and  on  IBM  personal  computer  (PC)  or  equivalent  devices  that  have  an 
asynchronous  communications  adaptor  board.  The  system  is  seen  simply  as  another 
user  to  the  target  system.  It  does  not  know  and  has  no  need  to  know  what  hardware, 
software,  or  database  management  system  (DBMS)  is  used  at  the  remote  location. 
All  it  needs  to  know  is  that  data  is  to  be  sent  in  asynchronous,  American  Standard 
Code  for  Information  Interchange  (ASCII)  format. 

Once  the  full  range  of  TLRN  capabilities  is  operational,  the  user  will  be  able  to 
either  access  a  remote  host  directly,  which  would  require  familiarity  with  the  host 
operating  system,  or  use  the  TLRN  capabilities  to  execute  batch  programs  to  retrieve 
the  requested  information  from  remote  systems,  all  transparent  to  the  user.  In  both 
cases,  the  user  would  be  able  to  take  advantage  of  downloading  and  post-processing 
routines  developed  to  meet  user-specific  needs. 

2.3  AIR  FORCE  TELECOMMUNICATIONS  REQUIREMENTS 

Air  Force  policy  for  telecommunications  implementation  is  presented  here  in 
the  context  of  the  Unified  Local  Area  Network  Architecture  (ULANA)  initiative. 
The  Automated  Technical  Order  System  (ATOS)  and  the  Engineering  Data 
Computer  Assisted  Retrieval  System  (EDGARS)  provide  information  on  the 
technical  requirements  for  transmission  of  technical  data  and  engineering  drawings 
respectively.  This  section  also  discusses  two  IG  efforts  in  the  Air  Force  —  the 
Central  Datacomm  System  (CDS)  and  the  Logistics  Data  Information  System 
(LOGDIS). 

2.3.1  Air  Force  Communications  Policies  and  Standards 

In  the  last  decade,  new  classes  of  problems  have  emerged  as  Air  P'orce  planners 
and  system  developers  have  faced  the  complexities  of  integrating  large  numbers  of 
independently  developed  automated  capabilities.  The  goals  of  linking  real-time 
computer  programs  with  LANs  and  long  haul  digital  data  communications  to 
achieve  intersystem  communications  of  major  Air  I'orce  systems  rec^uired  major 


software  and  hardware  reengineering  and  system  integration  based  on  advanced 
information  system  technologies. 

The  purpose  of  the  ULANA  I  program  is  to  create  a  set  of  standard  components 
for  implementing  data  communications  networks  for  unclassified  and  classified  data 
on  Air  Force  Bases  to  provide  communications  among  heterogeneous  hosts  and 
terminals.  The  ULANA  I  component  requirements  will  allow  a  wide  variety  of 
architectures  to  be  implemented  so  that  almost  all  Air  Force  LAN  requirements  can 
be  met.  It  can  be  used  by  a  large  percentage  of  current  Air  Force  terminals  and 
hosts,  which  include  everything  from  PCs  to  mainframes. 

The  ULANA  I  implementations  will  provide  terminal-to-host,  host-to-host,  and 
terminal-to-terminal  communications.  DDN  gateways,  facilities  for  network 
management,  and  bridges  to  connect  subnetworks  will  also  be  provided.  The 
American  National  Standards  Institute  (ANSD/IEEE  Standard  802.3  protocol  and 
standard  DoD  protocols  are  required  for  all  ULANA  I  components  and  the 
distribution  system.  The  Air  Force  plans  to  upgrade  ULANA  I  installations  to 
ULANA  II,  which  will  use  capabilities  that  are  not  technically  feasible  now  or  are 
based  on  standards  that  are  not  yet  complete.  Examples  of  these  capabilities  include 
the  ISO  protocols,  IEEE  802.1  network  management  standard,  and  multilevel 
network  security. 

ULANA  I  components  will  operate  on  the  following  media: 

•  Broadband  coaxial  cable  (single-  and  dual-cable  systems)  as  described  in 
IEEE  802.7,  with  the  exception  that  the  coaxial  cable  systems  will  comply 
with  the  delay,  budget,  and  diameter  constraints  defined  in  IEEE  802.3  and 
that  the  minimum  loop  loss  will  be  the  loss  of  that  described  in  IEEE  802.7 
or  44  decibels  (dB),  whichever  is  lower,  and  the  maximum  loop  loss  will  be 
the  greatest  of  that  described  in  IEEE  802.7  or  56  dB,  whichever  is  higher. 

•  Baseband  coaxial  cable,  as  described  in  IEEE  802.3  and  IEEE  802. 3A. 

•  Dual-window  optical  fiber  cable  with  an  outer  cladding  diameter  of 
125  microns.  Other  characteristics  are  to  be  defined  by  the  contractor. 

The  following  protocols  will  be  implemented  as  depicted  in  Figure  2-5; 

•  Applications  Utility  Layer  Protocols  —  SMTP,  FTP.  TELNET,  and  an  IHM 
PC-compatible  NETBIOS  will  be  implemented  above  the  transport  lava  r 
protocols  on  IBM  PCs  and  Zenith  248s  running  DOS  3.1,  DOS  3.2,  and 
Xenix  2.0,  and  VAX  78()s  and  Micro  VAX  IIs  running  Ultrix  1 .2. 
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•  Transport  Layer  Protocols  —  TCP  and  the  User  Datagram  Protocol  (UDP). 


•  Network  Layer  Protocols  —  IP,  the  Internet  Control  Message  Protocol 
(ICMP),  and  IP  address  to  Media  Access  Control  (MAC)  address  translation. 


•  MAC  Sublayer  and  Physical  Layer  Protocols  —  Implemented  as  specified  in 
IEEE  802.2,  Standard  Network  Access  Protocol  (SNAP)  implementation, 
IEEE  802.3,  IEEE  802.3A,  and  IEEE  802.3B. 


•  Exterior  Interface  Protocols  —  The  Exterior  Gateway  Protocol  (EGP)  and  a 
certified  DDN  X.25  standard  interface. 


Note:  FTP  »  File  Transfer  Protocol.  SMTP  »  Simple  Mail  Transfer 
Protocol;  TCP  «  Transmission  Control  Protocol;  UDP=  User  Datagram 
Protocol;  IP  =  Internet  Protocol;  ICMP  =  Internet  Control  Message 
Protocol;  EGP  =  Exterior  Gateway  Protocol;  MAC  =>  Media  Access 
Control 


FIG.  2-5.  ULANA I  PROTOCOLS 


ULANA  II  enables  the  ULANA  program  to  transition  to  the  ISO  protocols.  All 
ULANA  n  data  networking  components  are  based  on  the  anticipated  ISO  protocols 
depicted  in  Figure  2-6.  Any  Air  Force  applications  that  must  use  the  DoD  protocol 
suite  during  the  ULANA  II  life  cycle  will  be  interconnected  to  the  ULANA  II 
networks  via  the  OSI/DoD  Application  Layer  gateway  being  developed  by  NBS 
under  contract  to  DCA.  This  gateway  provides  automatically  staged  translations 
between  FTP  and  FTAM,  TELNET  and  Virtual  Terminal  Protocol  ( V'TP),  and  SMTP 
and  X.400. 


The  ULANA  II  networking  multilevel  security  approach  is  based  on  the  three 
layers  of  encryption  being  standardized  in  the  ISO  community  by  ANSI.  Link 
encryption  is  to  be  provided  at  the  Data  Link  Layer  by  ANSI  X3. lO.'j- 1983  or  its 
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Note:  ISO  =  international  Standards  Organization;  CASE  =  Common  Application 
Service  Elements;  CCR  =  commitment,  concurrency,  and  recovery,  SASE  =  Specific 
Application  Service  Elements,  JTM  =  Job  Transfer  and  Manipulation,  VTP  =  Virtual 
Terminal  Protocol;  X  400  =  CCITT  Message  Handling  Protocol,  FTAM  =  File  Transfer. 
Access,  and  Management;  TP-4  =  Transport  Protocol  Class  4,  IEEE  =  Institute  of 
Electrical  and  Electronic  Engineers;  LLC  =  Logical  Link  Control  MAC  =  Media  Access 
Control;  FDDI  =  Fiber  Distributed  Data  Interface.  ISDN  =  Integrated  Services  Digital 
Network 


FIG.  2-6.  ARCHITECTURE  OF  ULANA  II  CONCEPTUAL 
PROTOCOL  SUITE 
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successor.  End-to-end  encryption  in  a  nonstorage  channel  (i.e.,  an  end-to-end 
channel  that  offers  no  store-and-forward  capabilities)  is  to  be  provided  at  the 
Transport  Layer  by  ANSI  X3T1-85-50  or  its  successor.  Process-to-process 
encryption,  which  guards  against  security  threats  in  a  storage  channel,  is  to  be 
provided  at  the  Presentation  Layer  by  ANSI  X2T1-81-106.19  or  its  successor. 

The  ULANA  I  family  of  gateways  should  be  augmented  to  include  gateways  to 
the  emerging  ISDN  standards,  and  to  include  gateways  to  proprietary  networks. 
Application  Layer  gateways  are  used  to  interconnect  to  ULANA  II  any  Air  Force 
applications  and  hosts  that  obtain  waivers  to  continue  using  the  DoD  protocol  suite. 
DCA  intends  to  commercialize  these  gateways  via  the  NBS  development  effort. 

Furthermore,  to  the  extent  that  DDN  will  transition  to  an  ISO-based  protocol 
suite  within  the  ULANA  11  life  cycle,  appropriate  modifications  will  have  to  be  made 
in  the  ULANA  I  DDN  gateway  protocols  and  protocol  management  algorithms. 

2.3.2  Air  Force  Technical  Data  and  Engineering  Drawings  Modernization  Efforts 

The  Automated  Technical  Order  System  (ATOS)  is  an  automated  publications 
system  for  storage,  distribution,  revision,  and  updating  of  Technical  Orders  (TOs). 
i.e.,  documents  that  describe  how  to  operate,  maintain,  and  use  equipment  through 
narrative  text  and  illustrations.  ATOS  is  to  be  implemented  in  two  phases: 

•  Phase  I  —  TO  Publication  System 

►  Automate  TO  change  preparation 

►  Increase  organic  capabilities 

►  Digitize  selected  existing  TOs 

•  ATOS  Pilot  Program 

►  Automate  TO  distribution  at  Air  Logistic  Centers  ( ALCs)' Aerospace 
Guidance  and  Metrology  Center  (AGMC) 

►  Receive  aerospace  contractor  TO  in  digital  form 

►  Interface  with  Phase  I  for  TO  changes 

►  Management  of  TO  databases 

►  Digital  database  for  active  TOs. 


SYSCON  Corporation  is  the  contractor  for  Phase  I.  The  Phase  I  configuration  has 
been  installed  at  each  ALC  and  at  the  AGMC. 

The  request  for  proposals  (RFP)  for  the  Pilot  Progrr-m  will  include  a  subset  of 
B-IB  bomber  TOs  rather  than  all  Air  Force  TOs.  The  Pilot  Program  RFP  is 
scheduled  to  be  released  before  the  end  of  1987.  Contract  award  is  scheduled  for 
1988. 

The  Air  Force  expects  to  receive  data  in  digital  form  from  industry  on  magnetic 
or  laser  media  rather  than  over  communication  lines.  Requirements  have  yet  to  be 
defined  for  interfaces  that  warrant  use  of  DDN  or  other  communication  lines  for 
transmitting  data  to  the  other  Services  or  DLA.  There  may  now  be  an  occasional 
requirement  to  mail  up  to  one  page  of  data  to  one  of  the  other  Services. 

A  TRW,  Inc,,  proprietary  broadband  Carrier  Sense  Multiple  Access  with 
Collision  Detection  (CSMA/CD)  LAN  will  be  used  for  the  ATOS  in  the  local 
environment.  Host-to-host  connections  will  be  over  one  or  two  channels  on  this 
broadband  LAN,  using  the  Ethernet 802.3  standard.  Fiber  optics  have  been 
installed  at  two  ALCs;  more  are  to  be  installed  at  the  other  ALCs  in  the  future. 
Fiber  optics  can  provide  better  service  in  the  transmission  of  large  volumes  of  data  at 
the  Air  Force  Logistics  Command  ( AFLC)  bases. 

The  AFLC  LANs  are  also  comprised  of  a  separate  WANGNET  and 
Ungermann-Bass  networks  (broadband,  dual  cable).  A  prototype  intersite  gateway 
(ISG)  for  connections  with  the  DDN  has  been  developed  and  is  being  tested  under  a 
contract  with  ARINC  in  Annapolis,  Md.  Another  gateway  under  development  will 
provide  connections  to  the  Automatic  Digital  Network  (AUTODIN). 

Though  no  decision  has  yet  been  made  about  interface  standards,  they  should 
be  available  by  late  summer  FY87.  The  standards  relating  to  ATOS  include 
MIL-STD-1840,  which  calls  out  IGES,  SGML,  CCITT  Group  4,  and  Computer 
Graphics  Metafile  (CGM). 

The  Air  Force  has  conducted  an  ATOS  Pilot  System  Communications  Loading 
Study  to  project  traffic  loading  for  local  and  long-haul  communications  for  the  Pilot 
System,  based  on  Rockwell’s  standard  planning  factor  ( 100  pages  per  B-IB  TO)  for 
all  Rockwell  "make”  and  "buy”  B-IB  TOs.  Rockwell  describes  the  "typical  B-IB  ’fO  ” 
as  60  percent  text  and  40  percent  illustration.  Files  of  B-IB  T(3s  in  Rockwell  s 
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Automated  Technical  Publications  System  are  composed  of  ASCII  text  and 
vectorized  illustrations  compiled  directly  from  CAD/CAE  (computer-aided  engi 
neering)  systems  and  some  from  scanners  used  to  digitize  paper  drawings.  A  full 
page  of  TO  text  is  projected  at  5,000  bytes  per  page.  A  full  page  of  moderately 
complex  high-resolution  artwork  is  projected  at  400,000  bytes.  A  total  B-IB  TO  is 
estimated  at  16,300,000  bytes,  or  more  than  130  megabits  per  TO.  Estimated  traffic 


I  loading  characteristics  for  intersite  channels  are  listed  in  Table  2  4.  All  traffic 

loading  represents  raw  data  and  does  not  include  overhead.  Under  the  current 
AFLC  LAN  concepts,  both  inter-  and  intrasite  traffic  will  be  handled  via  the  AFLC 
LAN  cable  plant.  The  estimated  total  intersite  daily  traffic  loading  from  the  AFLC 
LAN  across  the  DDN  is  556  megabytes  (556  million  bytes). 


TABLE  2-4 

ATOS  DAILY  ESTIMATED  DDN  TRAFFIC  LOADING 


Sender 

Sent  to 

Number  of 
bytes  sent 

Oklahoma  City  ALC 

Sacramento  ALC 

326,S00,000 

Dyess  AFB 

16,300,000 

Ellsworth  AFB 

16,300,000 

Grand  Forks  AFB 

16,300,000 

McConnel  AFB 

16,300,000 

Sacramento  ALC 

Oklahoma  City  ALC 

163,500,000 

Dyess  AFB 

Oklahoma  City  ALC 

100,000 

Sacramento  Al.C 

100,000 

Ellsworth  AFB 

Oklahoma  City  ALC 

100,000 

Sacramento  ALC 

100,000 

Grand  Forks  AFB 

Oklahoma  City  ALC 

100,000 

Sacramento  ALC 

100,000 

McConnel  AFB 

Oklahoma  City  ALC 

100,000 

Sacramento  ALC 

100,000 

Total  daily  traffic 

556,000,000 

Note:  ALC  =  Air  Logistirs  Center,  AFB  =  Air  Fntre  Bdse 


If  the  chosen  architecture  for  ATOS  provides  for  telecommunication  ol  bit¬ 
mapped  (raster)  images,  the  loading  of  the  expected  intersite  I'O  transfers  would 
result  in  processing  over  4  gigabits  (4  billion  bits)  a  day.  Even  if  the  DDN  could 


provide  an  optimum  sustained  and  accurate  (no  data  losses,  no  contention,  and  no 
re  transmittals)  data  transfer  rate  of  56  kbps,  transferring  the  daily  load  would  take 
over  22  hours. 

The  traffic  loading  estimates  take  into  account  the  fact  that  the  most  efficient 
means  of  forms  processing,  from  a  communications  viewpoint,  is  to  store  the 
formatting  information  for  the  forms  at  the  user  workstation  rather  than  transmit 
the  formatting  data  with  user-entered  data.  In  addition,  a  system  design  based  on 
transmittal  of  "TO  changes”  instead  of  "changed  TOs”  and  provision  of  an  active 
indexing  system  that  automatically  verifies  currency  of  the  databases  would  reduce 
the  requirement  for  weekly  download  communications.  Therefore,  data  redundancy 
would  be  a  requirement  until  the  system  could  support  transfers  of  the  required 
volume. 

The  Engineering  Data  Computer  Assisted  Retrieval  System  (EDGARS)  is  an 
automated  system  for  capturing,  storing,  distributing,  revising,  and  updating  the 
engineering  drawing  information  currently  stored  in  paper  and  aperture-card  form. 
It  is  being  developed  by  the  Air  Force  jointly  with  the  Army’s  DSREDS. 

The  EDGARS  Data  Gommunications  (DAG)  subsystem  consists  of  one  front- 
end  processor  (FEP)  to  interface  remote  and  nonremote  devices,  and  a  LAN  to 
interface  high-speed  graphics  devices.  The  FEP  is  functionally  compatible  with  the 
IBM  3275  series  hardware;  the  NGR  Gomten  Advanced  Gommunications  Function/ 
Network  Gontrol  Program  (AGF/NGP)  software  is  functionally  compatible  with 
IBM’s  AGF/NGP. 

The  LAN  is  a  token  passing  bus  implementation  of  the  IEEE  802.4  standard 
via  coaxial  baseband  cable.  The  FEP  is  designed  to  use  SNA  with  the  Virtual 
Telecommunications  Access  Method  (VTAM).  The  protocol  employed  is  bisyn 
chronous  (BSG)  in  a  3270  environment.  Asynchronous  devices  access  the  system  via 
protocol  converters  and  look  like  BSG  3270s  to  the  Process  Gontroller. 

The  FEP  provides  communications  capability  for  up  to  75  user  graphic  display 
terminals  (GDTs)  operating  at  9,600  bits  per  second  (bps),  for  1  DDN  interface  at 
56  kbps,  for  up  to  50  user  video  display  terminals  (VDTs)  operating  at  1,200  bps,  and 
one  interface  at  9,600  bps  to  the  332  Aperture  Gard  Output  Gontroller.  'Fhe 


ALPHAREL  LAN  supports  a  minimum  speed  of  1  megabit  per  second.  Six  channels 
on  the  TRW  LAN  are  dedicated  to  EDGARS. 

Figure  2-7  represents  the  EDGARS  remote  terminal  and  DDN  communications 
architecture.  The  DDN  interface  is  provided  in  the  DAG  by  the  Gommunications 
Processor.  The  communications  portion  of  the  DDN  protocol  layers  will  run  in  the 
FEP.  The  applications  portion  of  the  DDN  protocol  layers  will  run  in  the  Process 
Gontroller.  The  Air  Force  believes  the  Gommunications  Processor  and  the  currently 
available  Process  Gontroller  interface  software  provide  the  best  available  working 
solution  to  the  complex  DDN  interface.  The  following  protocol  layers  will  be 
provided: 

•  Link  Layer  —  High-Level  Data  Link  Gontrol  (HDLG)  Distant  Host  (HDH) 
Interface 

•  Network  Layer  —  IP  (defined  by  MIL-STD-1777) 

•  Transport  Layer  —  TGP 

•  Session  Layer  —  TELNET 

•  Application  Layer  —  FTP,  SMTP. 

EDGARS  also  expects  to  use  a  subset  of  IGES  and  PDES,  MIL-STD-1840,  and  GGITT 
Group  4. 

Transferring  engineering  drawings  via  the  DDN  is  not  recommended  because 
of  slow  speeds  and  DDN  overhead.  However,  it  is  estimated  that  95—98  percent  of 
all  engineering  data  used  by  an  ALG  will  be  stored  at  that  center,  so  the  need  for 
long-haul  transmittal  of  drawings  will  be  minimal.  Today,  only  a  small  number  of 
the  total  requests  for  engineering  drawings  are  from  other  stations.  Although  there 
may  be  data  redundancy  between  stations,  each  station  will  make  modifications  to 
the  drawings  at  its  location  to  make  the  drawing  station  unique  to  accommodate 
site-specific  weapon  systems.  In  the  Air  Force,  there  is  a  greater  requirement  for 
long-haul  transmission  of  TOs  than  for  engineering  drawings. 

Although  Strategic  Air  Gommand  (SAG)  activities  could  benefit  from  the  use  of 
vector  data,  they  represent  only  1  percent  of  the  total  requests  for  engineering 
drawings.  For  that  reason,  and  because  the  technology  to  convert  raster  readily  to 
vector  is  not  available,  the  Air  Force  intends  to  support  raster  data  only.  Once  the 
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capability  is  available  to  convert  raster  to  vector  without  manual  intervention,  the 
Air  Force  will  consider  supporting  vector  data  in  its  databases. 

Today,  all  CAD  systems  and  their  terminals  are  proprietary.  There  is  not  a 
terminal  that  will  allow  a  user  to  access  different  graphics  systems.  For  this  reason, 
proprietary  AT&T  terminals  will  be  used  to  access  the  EDGARS.  Standards  must  be 
established  before  another  approach  is  feasible. 

The  Air  Force  feels  that  the  EDGARS  provides  a  capability  that  is  better  than 
the  manual  approach  used  today.  The  Air  Force  prepared  for  the  EDGARS  data 
conversion  effort  by  generating  new  aperture  cards  or  by  making  copies  of  the 
existing  aperture  cards,  which  were  then  read  by  laser  scanners  for  conversion. 

Any  digitized  data  received  from  industry  will  be  through  the  mail  on  magnetic 
or  laser  media  rather  than  over  communication  lines.  Basically,  one  Service 
procures  the  data,  then  reproduces  the  drawings  and  sends  it  to  the  other  Services. 
There  may  be  interface  requirements  with  EDMIGS  and  DSREDS,  although  specific 
requirements  have  not  yet  been  defined.  The  system  will  primarily  support  user 
access  to  the  data  stored  by  EDGARS. 

The  Gataloging  and  Standardization  Genter  (GASG)  in  Battle  Greek,  Mich., 
has  presented  a  needs  assessment  in  two  parts  to  the  EDGARS  program.  Part  A  is 
based  on  the  initial  intent  of  the  EDGARS  system  to  provide  technical  data  to  the 
user  through  the  use  of  GDTs.  The  projected  requirement  is  for  131,000  queries  a 
year.  While  there  is  no  requirement  to  modify  drawings,  access  to  both  proprietary 
and  nonproprietary  drawings  is  needed. 

Based  on  these  requirements,  GASG  has  requested  16  GDTs  with  printers.  It  is 
projected  that  the  additional  technical  data  support  provided  by  EDGARS  could 
result  in  a  5-year  logistics  cost  avoidance  of  over  $1.9  million.  A  decrease  of 
1,850  items  requiring  entry  into  the  Federal  Supply  System  (annually)  due  to 
increased  availability  of  technical  data  has  been  projected.  The  projected  cost 
avoidance  takes  into  consideration  both  previously  stocklisted  and  not  previously 
stocklisted  items. 

Part  B  of  the  GASG  response  is  based  on  what  they  see  as  a  potential  enhance 
ment  of  the  system,  inclusion  of  provisioning  data.  It  is  estimated  that  a  total  of 
336,000  provisioning  drawings  a  year  will  be  added  to  the  system.  It  is  also  projected 
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that  CASC  technicians  will  submit  approximately  200,000  queries  a  year  to  this 
database.  What  additional  hardware  may  be  needed  to  meet  this  requirement  has 
not  been  determined. 

The  potential  benefits  fall  into  two  categories:  the  administrative  cost  savings 
associated  with  eliminating  the  need  to  manually  manage  hard  copy  aperture-card 
data,  or  both,  and  the  cost  avoidance  realized  through  the  improved  ability  to 
prevent  duplicate  and  less  preferred  items  from  entering  the  Federal  Supply  System. 
Though  cost  avoidance  is  hard  to  estimate,  CASC  regards  the  potential  payback  for 
CASC  and  the  rest  of  the  command  as  significant.  Acquiring  technical  data  will 
continue  to  be  a  primary  purpose  of  CASC’s  efforts  in  the  coming  months. 

The  present  EDCARS  contract  will  end  in  1988.  The  Sacramento  ALC  will 
most  likely  become  the  lead  ALC  through  the  AFLC  for  continuing  EDCARS  efforts. 
The  EDCARS  concept  will  then  be  expanded  to  include  Configuration  Control 
Management,  Provisioning  and  Cataloging  Data,  and  other  areas  as  enhancements 
of  the  current  design. 

2.3.3  Intelligent  Gateway  Projects 

The  Air  Force  has  recently  awarded  a  contract  for  development  of  the  Central 
Datacomm  System  (CDS),  which  will  be  the  front  end  for  all  large  computer  systems 
in  the  Air  Force  Systems  Command  (SYSCOM).  It  will  serve  as  the  single  point  of 
access  for  anyone  attempting  to  access  SYSCOM  systems  from  off-base.  The  CDS 
will  basically  have  the  same  functionality  as  LOGDIS  under  development  in  the 
Logistics  Command,  but  unlike  the  LOGDIS  will  not  support  such  office  automation 
functions  as  spreadsheets.  The  CDS  is  to  support  DDN  protocols  over  Ethernet. 

SYSCOM  has  requirements  to  support  access  to  a  heterogeneous  environment 
that  includes  Control  Data  Corporation  (CDC)  Cybers,  Crays,  VAX,  Eclipse,  and 
Pyramids.  A  few  of  the  goals  of  the  CDS  project  are:  to  reduce  the  myriad 
connections  between  user  stations  and  the  Aeronautical  Systems  Division  (ASD) 
Information  Systems  and  Technology  Center  (ISTC)  computer  systems;  increase  the 
functionality  and  speed  of  transfer  of  user  data  to  and  from  the  ISTC;  provide  a 
single  point-of-entry  for  user  and  account  validation  and  resource  authorization;  and 
provide  a  focused,  controlled  point-of-connection  between  Wright-Patterson  Air 
Force  Base  (WPAFB)  LANs  and  the  ISTC. 


The  System  Program  Offices  (SPOs)  and  SPO  support  organizations  comprise  a 
large  portion  of  the  ASD  community.  They  plan,  develop,  and  manage  the 
acquisition  of  new  aeronautical  systems.  These  efforts  include  upgrading  existing 
aircraft,  such  as  the  F-15  and  F-16  fighters,  and  development  and  procurement  of 
new  aircraft,  such  as  the  B-IB  bomber  and  the  C-17  transport.  Computer  support  in 
engineering  is  provided  by  several  organization-owned  VAX  minicomputers  and 
microcomputers  (e.g.,  Zenith-lOOs). 

In  addition,  the  SPOs  and  supporting  organizations  depend  heavily  on  the 
processing  capability  of  the  ISTC  computer  systems.  There  are,  at  present,  few 
engineering  support  networks  within  the  SPOs  and  supporting  organizations. 
However,  this  will  change  with  the  acquisition  of  the  scientific  engineering 
workstations  (SEWs)  in  the  near  future.  [ASD  has  recently  awarded  a  contract  for 
development  of  the  SEWs,  which  is  to  serve  as  a  standard  source  of  supply  for  both 
SYSCOM  and  the  Logistics  (LOG)  Command.] 

The  TRW  LAN  supports  the  ASD  systems.  It  is  a  CSMA/CD  broadband  dual 
cable  LAN,  able  to  support  as  many  as  240  channels.  Two  56  kbps  circuits  to  DDN 
are  now  used;  this  number  may  grow  to  five.  The  CDS  will  eventually  interface  to  at 
least  16  T-1  circuits  supported  by  the  DCTN.  A  Digital  Equipment  Corporation 
Network  (DECNET)  LAN  is  also  used  to  support  ASD  operations.  There  is  a  future 
requirement  to  interface  with  weapon  system  contractors.  There  are  a  few 
connections  today  over  dedicated  lines  with  contractors  such  as  Rockwell  and 
Boeing.  The  Air  Force  is  working  on  similar  connections  with  General  Electric  (for 
the  F-16)  and  McDonnell-Douglas  (for  the  C  17). 

The  Logistics  Data  Information  System  (LOGDIS)  Intelligent  Gateway 
Processor  (IGP)  provides  tools  for  managing  data  within  the  office  and  for  connecting 
the  office  to  outside  sources  of  information.  The  IGP  automates  and  provides  access 
to  multivendor  hosts  via  the  DDN,  asynchronous  RS-232C  interfaces,  or  LANs. 
Software  support  automates  access  to  other  host  computers,  data  retrieval,  security 
processing,  and  control  of  information  resources.  The  IGP  also  provides  functional 
software,  such  as  electronic  mail,  personal  calendar  system,  word  processing, 
spreadsheet  programs,  relational  DBMS,  user-oriented  menus,  system 
administration  menus,  and  routines  for  maintaining  software,  'fhe  UNIX  operating 
system  is  the  foundation  of  the  IGP;  the  IGP  software  is  therefore  not  vendor  specific 
although  it  is  operating  system  specific.  The  Air  Force  intends  to  provide  office 
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automation  functions  through  a  separate  multi-Service  system  development  effort. 
The  office  automation  functions  would  then  be  removed  from  LOGDIS.  The  goal  in 
the  Air  Force  is  to  build  simple  gateways  that  allow  the  user  access  to  heterogeneous 
systems.  However,  the  office  automation  capabilities  are  so  integrated  in  the 
LOGDIS  IGP  that  separating  them  from  the  gateway  may  be  difficult. 

The  LOGDIS  IGP  operates  in  an  asynchronous  terminal  environment,  selects 
optimum  communications  pathways,  translates  protocols  through  external  protocol 
emulators,  provides  the  host-to-host  dialogue,  translates  files,  and  offers  post 
processing.  LOGDIS  also  provides  overall  transaction  control,  accounting,  and 
security.  Interactions  with  users  are  menu-driven  and  self-guided,  and  on-line  help 
for  several  levels  of  expertise  is  offered.  The  user  must  be  familiar  with  the  selected 
resource,  since  search  negotiation  must  proceed  according  to  the  syntax  and  logic  of 
the  target  system.  Extracted  information  can  be  placed  in  data  files  for  subsequent 
postprocessing,  analysis,  and  graphical  display. 

The  latest  versions  of  the  operational  LOGDIS  IGP  have  been  installed  at 
WPAFB  and  at  Hill  AFB  on  a  PLEXUS  P-60  machine.  The  IGPs  serve  as  hosts  on 
the  AFLC  LANs  (Figure  2-8)  to  supply  intelligent  processing  for  dumb  terminals. 
Not  all  terminals  will  pass  through  the  gateway;  only  those  users  that  require  the 
intelligence  provided  by  the  gateway,  such  as  transparent  connectivity  to  a  local  or 
remote  host  or  the  capability  to  down-load  information  from  a  host  for  further 
manipulation,  will  be  connected.  Users  will  have  the  ability  to  tailor  an  IGP  to  their 
unique  applications. 

One  component  of  the  Integrated  Design  Support  (IDS)  System  involves 
development  of  a  prototype  MULTIBASE  front  end  to  enable  Air  Force  personnel 
and  aerospace  contractors  and  subcontractors  to  gain  access  to  design  manufacturing 
and  engineering  data  on  the  development  of  weapon  systems.  This  work  is  being 
performed  by  the  Computer  Corporation  of  America  (CCA)  as  a  subcontractor  tcj 
Rockwell  International,  the  prime  contractor  for  B-IB  bomber  development. 
Interfaces  must  also  be  provided  for  AFLC  and  the  many  other  second-  and  third-tier 
subcontractors  in  the  B-IB  program. 

MULTIBASE  is  a  software  system  that  provides  a  uniform,  integralt'd 
interface  for  retrieving  data  from  heterogeneous,  distributed  databases.  Because  it 
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Nott:  DON  =  Defense  Data  Network,  ISG  =  mtersite  gateway,  IP  =  internet  Protocol;  iCMP  =  internet  Control  Message 
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FIG.  2-8.  PROPOSED  LOCAL  AFLC  LAN  ARCHITECTURE 

features  an  integrated  schema  and  a  single  query  language,  familiarity  with  one 
system  interface  is  all  that  is  needed. 

The  language  provided  to  global  users  by  MULTIBASE  is  DAPLEX,  a  data 
definition  and  manipulation  language  for  database  systems.  DAPLEX  provides  a 
natural  language  interface  to  the  database.  The  component  architecture  of 
MULTIBASE  is  illustrated  in  Figure  2-9.  MULTIBASE  has  two  types  of  modules;  a 
global  data  manager  (GDM)  and  a  local  database  interface  (LDI).  All  global  aspects 
of  a  query  are  handled  by  the  GDM,  and  all  specific  aspects  of  a  local  system  are 
handled  by  an  LDI.  There  is  one  LDI  for  each  local  DBMS  accessed  by  MULTIBASE. 

DAPLEX  can  pull  together  the  two  disparate  codasyl  and  relational  data 
models.  Through  .MULTIBASE,  relatively  powerful  views  can  be  constructed  over 
lower-level  schema. 
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FIG.  2-9.  MULTIBASE  COMPONENT  ARCHITECTURE 

The  Air  Force  MULTIBASE  system  is  being  implemented  on  a  VAX  11/780  to 
interface  with  ORACLE  and  the  Relational  Information  Management  (RIM)  DBMS 
on  the  same  VAX  11/780.  The  technical  feasibility  of  this  approach  is  still 
questionable.  Security  restrictions  and  data  dictionary  incompatibilities  must  be 
overcome.  The  data  dictionary  is  expected  to  require  between  1  and  10  gigabytes  of 
storage.  Other  considerations  include  a  capability  for  network  transaction 
management,  file  transfer,  executive  control  system,  and  rules  for  configuration 


management.  Some  of  these  considerations  will  be  addressed  in  the  prototype,  and 
other  problems  may  be  identified. 

Response  time  is  an  issue  in  any  MULTIBASE  implementation,  and 
performance  has  not  yet  been  addressed.  As  an  interim  measure,  however, 
MULTIBASE  can  provide  a  user  community  with  an  ad  hoc  means  to  quickly 
generate  reports  that  today  require  from  6  months  to  more  than  1  year  from  request 
through  implementation. 

The  Air  Force  policy  is  to  use  the  Structured  Query  Language  (SQL)  as  the 
standard  database  language.  The  Air  Force,  Army,  and  Navy  have  signed  a 
memorandum  of  agreement  to  develop  a  standard  database  machine  to  be  used  as  a 
standard  component  in  applicable  systems.  Future  acquisitions  will  focus  on  issues 
related  to  security  in  the  DBMS  environment. 

2.4  ARMYTELECOMMUNiCATIONS  REQUIREMENTS 

This  subsection  describes  communications  architecture  concepts  and  strategies 
underway  in  various  Army  Commands,  including  the  Army  Materiel  Command 
(AMC)  and  the  Army  Information  Systems  Command  (ISC).  Army-wide 
telecommunications  requirements  for  CALS  are  being  developed  by  the  Army 
Communications  —  Electronics  Command  (CECOM).  In  addition,  the  DSREDS 
Project  is  discussed  in  terms  of  the  status  and  major  issues  associated  with 
automating  the  Army’s  repositories  of  engineering  drawings.  A  brief  description  is 
also  given  of  the  MULTIBASE  effort  as  the  Army’s  approach  to  the  use  of  IGs. 

2.4.1  Network  Initiatives  in  the  Army 

Every  major  command  in  the  Army  is  developing  an  overall  telecom 
munications  architecture  to  be  submitted  to  Headquarters  (HQ)  Army.  The  Army 
Materiel  Command  (AMC)  has  developed  an  overall  installation  architecture.  The 
AMC  strategy  classifies  LANs  into  one  of  two  types;  a  closed  or  "local”  LAN  and  an 
installation  or  post-wide  LAN.  The  local  LANs  are  typically  self-contained 
networks,  with  relatively  few  users  working  on  an  application  of  limited  interest  to 
the  post  or  base  as  a  whole.  The  post-wide  LAN  provides  connections  to  post 
computers,  access  to  DDN,  and  communications  for  office  automation  functions. 
Implementation  of  these  LANs  will  enable  users  to  query  all  of  AMC's  databases 
from  a  single  terminal. 


AMC  believes  that  all  DDN  requirements  can  be  satisfied  by  DDN-to-LAN 
gateways  and  need  not  affect  the  design  of  the  LAN  itself.  These  DDN-to-LAN 
gateways  will  be  the  preferred  method  of  connecting  to  DDN,  since  they  impose  the 
fewest  restrictions  on  the  user.  Devices  not  compatible  with  DDN  can  still  be  used 
on  the  LAN,  since  the  gateway  would  resolve  the  incompatibilities  and  provide  the 
DDN  connection.  It  is  also  much  simpler  to  install  and  maintain  one  or  a  few 
network  connections  to  DDN  than  many  different  device  connections. 

The  present  approach  in  the  overall  AMC  network  architecture  is  to  merge  the 
communications  center  function  with  the  automation  functions.  That  is,  all  message 
traffic  will  be  received  through  a  gateway  on  the  LAN  rather  than  through  a 
separate  message  center,  as  is  done  today.  A  number  of  computers  will  therefore  be 
connected  directly  to  the  AUTODIN  or  DDN  for  the  receipt  of  message  traffic. 
Transaction  and  batch  processing  will  be  received  through  an  FEP. 

AMC  hardware  configurations  consist  of  IBM-compatible  equipment  running 
under  MVS  and  UNIX-based  operating  systems.  Access  to  this  hardware  is  either 
through  a  direct  connection,  LAN,  dial-up,  AUTODIN,  DDN,  or  some  combination. 

AMC  is  developing  its  LAN  plans  within  the  set  of  LAN  technical  standards 
and  planning  guidelines  for  overall  Army  use  developed  by  ISC.  Approximately 
40  LANs  have  been  identified  and  approved  for  use  within  AMC.  The  intention  is  to 
use  fiber  optics  with  a  mix  of  coax  and  twisted-pair  cable. 

The  U.S.  Army  Information  Systemn  Command  (USAISC)  has  developed  an 
architecture  plan  to  meet  the  base  information  transfer  aspect  of  its  information 
systems  mission  over  the  next  decade.  ISDN  technology  will  be  the  architecture  of 
choice  for  long-term  Army  base  information  transfer  modernization  actions.  This 
includes  a  local  high-speed  information  transfer  network  at  the  end  of  many  of  the 
ISDN  digital  local  loops  to  handle  the  high  level  of  internal  office'unit  information 
transfer  needs,  while  maintaining  connectivity  and  single-line-unique  numbering 
for  the  individual  information  devices. 

The  strategic  and  long-haul  information-transfer  requirements  for  external 
Army  base  communications  will  be  satisfied  by  the  Defense  Communications  System 
(DCS)  and  commercial  carriers.  'I'he  primary  DCS  service  for  data  communications 
is  the  DDN. 


The  information  system  for  the  sustaining  base  in  CONUS  will  use  numerous 
cable  technologies  as  the  transmission  media.  Fiber  optics  will  be  the  cable 
technology  of  choice  for  use  at  Army  Bases.  The  cable  system  on  the  Army  Bases 
will,  of  necessity,  be  a  mix  of  fiber  optic,  coax,  and  copper  cable. 

The  fiber  optic  cable  will  be  used  for  the  high-speed  (1.544  Mbps  and  greater) 
digital  information  transfer.  The  lower  speed  digital  information  transfers  will  use 
copper  cables.  The  fiber  optic  cable  system  at  Army  Bases  will  evolve  from  two 
directions  —  the  long-term  ISDN  basewide  modernization  and  the  near-  to  mid-term 
office/unit  information  transfer  initiatives. 

Long-term  ISDN  basewide  modernization  will  focus  on  the  ISDN  switches  and 
the  fiber  optic  cable  network  to  connect  these  ISDN  switches.  This  fiber  optic  cable 
network  will  form  the  nucleus  of  the  base  digital  backbone  network.  The 
transmission  of  data  through  the  interswitch  trunks  will  be  typical  of  the 
information  transfer  service  of  the  base  digital  backbone  network.  Channels  of 
1.544  Mbps  (or  n  X  1.544  Mbps)  are  multiplexed  into  a  higher  rate  digital  signal  and 
transmitted  over  the  fiber  optic  cable.  The  fiber  optic  base  digital  backbone  network 
must  also  support  high  speed  (n  X  1.544  Mbps)  digital  information  transfer  service 
for  computers  and  end-user  information  devices. 

This  architecture  may  not  satisfy  all  requirements.  We  also  recognize  that 
networking  will  evolve  and  define  new  information  services  and  protocols.  These 
new  information  services  and  protocols  will  be  incorporated  in  the  architecture  as  it 
becomes  feasible. 

STARNET  is  the  concept  for  the  Army’s  integrated  worldwide  network  of 
computer  processors  and  peripherals  that  is  the  primary  provider  of  information 
processing,  storage,  display,  and  network  services  for  the  sustaining  base. 
STARNET,  a  subset  of  the  sustaining  base  portion  of  the  Army  Information 
Architecture,  relies  heavily  on  other  standard  systems  for  supporting  services,  such 
as  networking.  More  than  90  sites  are  planned  for  STARNET  facilities. 

The  1992  STARNET  is  seen  as  a  highly  distributed,  richly  connected  set  of  user 
sites.  True  multilevel,  secure  operating  systems  will  still  be  a  high-risk  technology. 
However,  low  cost  but  high  throughput  processing  and  encryption  technology  could 
allow  the  user  to  perform  multilevel  file  transfer  into  a  desk  or  a  portable  work 
station  and  operate  each  device  at  the  highest  level  of  access  allowed  to  the 


individual  user.  Network  standards  will  be  ISDN  and  OSI,  with  fifth-generation 
languages  becoming  the  norm  for  complex  tasks. 

Currently  the  Army  has  large,  disjointed  data  networks.  In  addition,  they  use 
close  to  3,000  Government  and  commercial  leased  data  circuits.  STARNET  will  take 
advantage  of  the  large  investment  and  capability  that  exists  in  these  networks. 
Since  STARNET  will  rely  on  commercially  available  products,  the  pace  of  the 
evolution  of  the  network  will  be  set  by  technologies  such  as  OSI,  multilevel  security 
(MLS)  such  as  the  BLACKER  technology,  and  ISDN. 

The  initial  phase  of  the  CECOM  effort  documented  the  current  paper-based 
logistic  support  information  system  by  surveying  Army  users  to  establish  data  flow 
patterns,  demand  rates,  storage  requests,  and  usability  criteria.  This  data  collection 
and  requirements  analysis  has  produced  a  conceptual  architecture  for  the 
implementation  of  CALS  in  the  Army.  CECOM  recently  published  its  draft  of  the 
CALS  Existing  Data  Communications  Baseline,  which  provides  information  on; 
(1) critical  CALS  information  data  flow  between  selected  sites;  (2)  a  quantitative 
analysis  of  the  existing  data  flow  for  each  CALS  site;  and  (3)  existing  DDN 
architecture,  connectivity,  equipment  availability,  and  usage.  The  Army  CALS 
technical  information  flow  between  major  Army  commands  and  industry  is  depicted 
in  Figure  2-10. 

The  report  depicts  existing  volume  for  text,  engineering  drawings,  and 
illustrations,  which  are  now  exchanged  largely  in  hard  copy  form  and  microfilm. 
Volume  is  defined  as  total  pages  or  page  equivalents  per  year  to  and  from  each 
organization.  Page  size  for  all  the  calculations  is  8  ^  inches  by  11  inches.  Total  bits 
per  page  has  been  computed  to  be  42,000  bits/page  for  text  and  512,000  bits/page  for 
engineering  drawings.  Table  2-5  shows  a  sample  of  data  transfer  requirements  for 
CECOM.  Bits  are  presented  in  billions  of  bits  per  year.  Appendix  C  presents  Army¬ 
wide  data  transfer  requirements. 


Note:  OA  I  Department  of  Army,  AMC  =  Army  Materiel  Command  iRADOC  ;  ''amine  and  Doctrine  C 
FORSCOM  =  Forces  Command,  RMS  =  Resource  Management  System,  EIR  =  Equipment  improvement  Recom  m 
NMP  =  National  Maintenance  Point;  SPT  =  support,  DESCOM  =  Depot  Systems  Command  ( DSiS  =  Care  of  S 
Storage,  DOC  =  documentation 


FIG.  2-10.  ARMY  CALS  TECHNICAL  INFORMATION  FLOW 
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The  report  also  contains  an  analysis  of  the  existing  Army  DDN  facilities  and 
provides  information  on: 

•  DDN  facilities  locations 

•  The  identification  of  DDN  PSNs  Interface  Message  Processors  (IMPs) 

•  The  identification  of  DDN  host  processors  at  each  location 

•  The  identification  of  TACs  at  each  location. 

Copies  of  the  report  may  be  obtained  from  CECOM  at  Fort  Monmouth,  N.J. 

2.4.2  Army  Engineering  Drawing  Modernization  Efforts 

The  DSREDS  is  being  developed  by  AT&T  at  Redstone  Arsenal,  Ala.  The 
overall  DSREDS/EDCARS  contract  is  managed  by  the  Army.  The  Air  Force  is 
responsible  for  and  manages  its  own  side  of  the  project.  The  system  will  serve  as  a 
builder  of  technical  data  packages  for  procurement.  Approximately  2,500  images 
are  retrieved  each  day  for  building  procurement  packages  at  Redstone  Arsenal.  The 
typical  technical  data  package  has  20  —  25  drawings  (200  megabytes  of  images),  with 
a  requirement  to  reproduce  40  copies  of  each  package.  This  results  in  a  tremendous 
number  of  cards  that  must  be  generated  and  distributed  throughout  the  local 
environment. 

DSREDS  technical  requirements  include  the  ability  to  input  950  aperture 
cards  per  hour  and  20  "C”  size  hard  copy  drawings  per  hour.  ( Drawings  range  in  size 
from  A  through  E,  C  being  the  average-size  drawing.)  Interactive  engineering  data 
retrieval  requirements  include  3-minute  response  time  for  retrieval  of  25  "C”  size 
drawings  within  3  minutes  to  be  displayed  on  25  dilTerent  remote  GDTs.  There  are 
also  requirements  to  be  able  to  generate  the  microfilm  for  1,700  images  per  hour, 
produce  9,600  copies  of  aperture  cards  per  hour,  and  to  plot  a  full-size  high-resolution 
plot  of  an  "E”  size  drawing  in  less  than  3  minutes. 

Based  upon  system  performance  requirements,  the  Government  originally 
projected  that  it  would  take  4  months  to  load  the  existing  images  at  the  Army 
Missile  Command  (MICOM).  Because  of  a  number  of  problems,  it  appears  that  it 
will  take  50  percent  longer.  P'or  example,  more  than  40  percent  of  the  aperture  cards 
are  not  scannable,  for  a  variety  of  reasons.  AT&T's  response  to  the  Army's  RFP 
proposed  to  design  a  system  to  read  and  store  drawings  based  on  the  Government 


specifications  provided  to  them.  However,  the  specifications  were  not  followed  by 
Government  and  contractor  personnel  when  the  drawings  were  originally  made. 

The  Air  Force  alleviated  some  of  the  physical  problems  associated  with  storage  and 
age  of  the  drawings  by  generating  new  cards  or  making  copies  of  the  old  aperture 
cards.  The  Army  used  its  original  cards,  many  of  which  had  degraded  as  a  result  of 
long  periods  of  storage. 

All  the  companies  bidding  on  this  contract  proposed  using  off-the-shelf 
hardware  and  software.  AT&T,  after  contract  award,  became  aware  that  much  that 
was  needed  to  support  the  DSREDS/EDCARS  requirements  is  not  available  off-the- 
shelf.  AT&T  has  a  firm  fixed-price  contract  with  the  Army  and  had  originally 
intended  to  invest  some  of  its  own  money  in  this  effort.  As  a  result  of  the  problems 
encountered,  many  of  which  were  unknown  at  the  time  of  contract  award,  AT&T  is, 
in  fact,  investing  a  substantial  amount  of  money  in  this  development  effort.  In 
consideration  of  failure  to  meet  contract  terms,  the  Army  has  received  a  value  of  over 
$7  million  in  enhancements.  The  enhancements  include  laser  printers,  improved 
scanners,  an  upgraded  central  processor  unit,  and  a  COMTEN  FEP.  The  Army  j 

suspended  on-site  acceptance  testing  for  57  days  while  AT&T  fixed  problems  with 
the  system. 

I 

Although  there  may  be  problems  in  implementing  the  system,  the  Army  is  I 

convinced  that  this  is  still  the  way  to  go.  The  system  to  be  replaced  by  DSREDS 
requires  five  customer  engineers  to  handle  maintenance  problems.  Parts  are  not 
available.  Maintenance  is  very  expensive,  and  the  system  is  down  one-third  to  one-  | 

half  of  the  time.  The  predominantly  manual  system  results  in  losses  of  data  from  ^ 

misfiled  cards.  The  digitization  of  data  would  be  permanent,  with  no  problems  from  Ij 

missing  cards.  5 


The  original  contract  includes  a  two-tier-oriented  set  of  options.  The  Air  Force  v 

■ 

has  obligated  all  its  money  by  exercising  all  of  its  options  (four  options  for  five 

i 

systems).  The  Army,  on  the  other  hand,  has  exercised  only  the  basic  system  and  one  \ 

option  out  of  six  options  for  seven  systems,  and  therefore  has  approximately  I 

I 

$22  million  left,  so  long  as  the  funding  remains  available.  •; 


The  Army  sees  a  need  to  communicate  not  only  between  the  EDGARS  and 
DSREDS  systems,  but  also  with  DLA  and  the  Navy.  In  past  procurement  efforts, 
there  have  been  areas  where  all  could  benefit  by  exchanging  engineering  drawings. 
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A  test  is  currently  underway  with  the  Sacramento  EDGARS  to  download  data  from 
the  Air  Force  system  to  the  Army  system. 

The  Army  plans  to  store  vector  data  in  a  library  that  will  be  available  for  access 
by  the  user.  The  Army  is  also  trying  to  define  vector-to-raster  requirements  so  that 
graphics  stored  in  vector  form  can  be  translated  into  a  two-dimensional  image  to  be 
stored  in  DSREDS.  AT&T  has  contracted  to  develop  a  CAD/CAM  (computer-aided 
manufacturing)  interface,  once  the  IGES  3.0  subset  standard  has  been  defined  for 
CALS.  The  Army  also  plans  to  add  a  Tech  Data  Configuration  Management  System 
(TDCMS).  Although  the  current  contract  does  not  provide  for  a  number  of 
capabilities,  the  intention  is  to  develop  a  system  that  can  be  upgraded  later  with 
enhancements. 

The  technical  data  packages  generated  by  DSREDS  at  the  Army  MICOM  at 
Redstone  Arsenal  will,  for  the  most  part,  be  transmitted  within  the  local 
environment  only.  Only  a  small  number  of  drawings  will  have  to  be  transmitted  to 
remote  locations  over  DDN.  It  will  be  3  to  4  years  before  the  broadband  network  is 
installed  at  Redstone  Arsenal.  The  Army  will  use  T-1  carrier  lines  initially  and  will 
then  convert  to  broadband. 

DDN  will  be  used  for  text  and  mail,  but  not  for  images.  Other  commands  have 
indicated  that  they  will  have  requirements  to  transmit  large  numbers  of  drawings  to 
remote  locations  over  DDN.  For  example,  the  Armament,  Munitions,  and  Chemical 
Command  (AMCCOM)  at  Picatinny  Arsenal  has  a  requirement  to  transmit  master 
bid  sets  and  aperture  cards  (an  average  of  1,500  aperture  cards  a  day)  to  Rock  Island 
Arsenal,  which  handles  all  supply  procurements.  At  an  average  of  8  megabytes  per 
image,  and  assuming  a  20:1  compression  ratio,  it  would  take  approximately  30  hours 
to  transmit  just  the  graphics  information  over  the  DDN.  This  estimate  includes  the 
25  percent  overhead  incurred  when  using  the  DDN.  Where  the  need  is  to  transmit 
only  a  few  drawings,  long-haul  communications  lines  (DDN)  could  prove 
satisfactory.  However,  where  large  numbers  of  drawings  must  be  transmitted, 
overnight  mail  would  be  more  efficient  and  faster. 

The  Army  is  concerned  by  the  proposed  CCITT  Group  4  standard  for  CALS. 
Group  4,  as  it  stands  today,  is  a  facsimile  standard  that  has  not  been  expanded 
beyond  the  8  ^inch  X  11  inch  size  drawing.  The  Group  4  "wraparound”  (a  modified 
version  of  CCITT  Group  4)  used  by  the  DSREDS/EDCARS  effort,  incorporates  an 


expanded  algorithm  that  accommodates  the  transmission  of  engineering  documen¬ 
tation  for  drawings  larger  than  "A”  size.  The  wraparound  version  performs  the 
functions  required  for  compressing  larger  size  engineering  drawings.  Testing  and 
research  recently  undertaken  by  West  Coast  Systems  and  Lawrence  Livermore 
National  Laboratories  (LLNL)  points  to  slight  advantages  in  speed,  number  of  bytes 
to  store,  and  overall  efficiency  to  using  the  wraparound  version,  with  virtually  little 
difference  between  the  two  versions. 

It  will  be  another  year  or  year  and  a  half  before  an  expanded  algorithm  is 
developed  for  Group  4.  The  DSREDS/EDCARS  effort  has  already  implemented  and 
stored  tens  of  thousands  of  drawings  based  on  the  wraparound  version.  Both  the 
Army  and  the  Air  Force  have  indicated  that  it  would  cost  DSREDS/EDCARS 
$3  million  to  $5  million  to  redesign,  retrofit,  and  reload  the  drawings.  As  an 
alternative,  pre-  and  post-processors  could  be  developed  to  convert  from  the 
wraparound  version  to  Group  4.  No  estimate  has  been  given  for  the  cost  associated 
with  the  development  of  these  translators.  The  Army  is  willing  to  support  the  logical 
choice  of  standard  in  this  area.  However,  both  the  Army  and  the  Air  Force 
recommend  that  CALS  adopt  the  Group  4  wraparound,  since  that  is  all  that  is 
available  today  and  there  is  no  proof  that  there  will  be  anything  better.  The  CALS 
Specifications  and  Standardization  Working  Group  is  addressing  the  issue. 

2.4.3  Intelligent  Gateway  Projects 

CCA  is  under  contract  with  AMC  to  develop  a  MULTIBASE  front  end  for  two 
DBMSs  resident  on  IBM  mainframes  (System  2000  DBMS  and  AMC’s  in-house- 
developed  Data  Management  Routines).  MULTIBASE  is  a  software  system  that 
provides  a  uniform,  integrated  interface  for  retrieving  data  from  preexisting, 
remotely  distributed,  heterogeneous  databases.  It  was  designed  to  allow  the  user  to 
reference  data  in  these  databases  with  one  query  language  over  one  database 
description  (called  a  schema).  MULTIBASE  enables  the  user  to  access  data  in 
multiple  databases.  Because  there  is  an  integrated  schema  and  a  single  query 
language,  the  user  has  to  become  familiar  with  one  system  interface  instead  of 
several.  The  MULTIBASE  architecture  is  described  in  Subsection  2.3.3. 

MULTIBASE  does  not  require  any  changes  in  existing  databases,  their 
DBMSs,  or  their  application  programs.  The  system  assumes  complete  responsibility 


for  knowing  the  location  of  the  local  databases,  accessing  the  data  at  each,  resolving 
data  incompatibilities,  and  combining  the  data  to  produce  a  single  result. 

A  conversion  of  MULTIBASE  to  full  Ada  is  included  in  the  contract  with  CCA. 
A  number  of  performance  enhancements  will  be  made  including  the  addition  of  a 
query  interrupt  capability.  MULTIBASE  will  run  under  the  VAX  VMS  operating 
system  and  a  gateway  (TCP/IP-Ethernet)  will  be  developed  to  interface  the 
VAX  11/780  to  the  IBM  hosts  using  the  TCP/IP  protocol  as  the  interface  standard. 
The  IBM  at  the  Automated  Logistics  Management  Systems  Activity  (ALMSA)  in 
St.  Louis,  Mo.  will  be  used  to  access  test  data  and  aid  development  of  the  system.  A 
prototype  implementation  will  be  installed  at  CECOM  at  Fort  Monmouth,  N.J. 

To  execute  multi-database  queries  correctly  and  efTiciently,  MULTIBASE  has 
to  solve  such  problems  as  transforming  a  query  expressed  in  the  user’s  global  query 
language  into  a  set  of  subqueries  in  the  languages  supported  by  the  different 
DBMSs;  formulating  an  efficient  plan  for  executing  a  sequence  program  for 
accessing  the  data  at  single  or  multiple  sites;  moving  and  storing  the  results  of 
subqueries;  resolving  incompatibilities  among  the  databases,  such  as  differences  in 
data  types,  and  conflicting  schema  names;  resolving  inconsistencies  in  copies  of  the 
same  information  that  are  stored  in  different  databases;  and  combining  the  data  into 
a  single  answer. 

Response  time  is  an  issue  in  any  implementation  of  a  data  retrieval  system  of 
multibase’s  scope  and  capabilities.  Significant  improvements  in  performance 
have  been  made  over  earlier  versions  of  the  MULTIBASE  software.  Additional 
improvements  are  planned  as  development  of  the  software  continues.  As  currently 
configured,  MULTIBASE  will  provide  dramatic  improvement  over  current  data 
retrieval  and  consolidation  activities  involving  multiple  heterogeneous  databases. 
Additional  improvements  are  expected  in  the  development  of  standard  reporting 
programs  and  systems  since  MULTIBASE  can  provide  a  user  community  with  an  ad 
hoc  means  to  quickly  generate  reports  that  today  can  require  from  6  months  to  more 
than  1  year  from  initial  request  through  final  implementation. 


SKCTION3 


TELECOMMUNICATIONS  INITIATIVES  IN  INDUSTRY 

In  this  section,  we  discuss  a  number  of  initiatives  now  underway  in  the  private 
sector  in  the  area  of  telecommunications,  including  MAP/TOP  and  the  NBS  GOSIP 
specification.  In  addition,  three  industry  efforts  to  provide  high-bandwidth  networks 
are  examined:  T-Carrier  Services,  the  emerging  ISDN,  and  FDDI.  Each  of  these 
digital  connectivity  mechanisms  makes  possible  higher  transmission  speeds, 
improved  error  performance,  and  higher  throughput  than  does  DDN.  They  are  at 
varying  stages  of  the  development  cycle  and  represent  the  current  undertakings  of 
the  communications  industry  to  provide  the  wide-bandwidth  service  that  will  be 
required  to  support  the  graphical/image  data  volumes  anticipated  by  the  CALS 
projects.  The  subsections  that  follow  explain  briefly  the  services  offered,  estimate 
the  expected  dates  of  availability,  and  examine  their  use  in  the  CALS  environment. 

3. 1  MANUFACTURING  AUTOMATION  PROTOCOL/ 

TECHNICAL  AND  OFFICE  PROTOCOL 

We  have  evaluated  the  MAP  suite  and  the  TOP  suite  to  determine  their  appli¬ 
cability  to  the  data  transmission  and  protocol  requirements  of  the  Service’s  CALS 
projects  and  to  determine  their  status  as  standard  architectures  in  the  private  sector. 
These  two  protocol  suites  are  the  primary  forces  driving  implementation  of  the  OSI 
communication  standards  in  the  United  States. 

The  purpose  of  both  MAP  and  TOP  is  interoperable,  multivendor,  nonpro¬ 
prietary  implementation  of  the  OSI  communications  standards.  Both  are  based  on 
the  OSI  seven  layer  architectural  model  developed  by  ISO.  Mainly,  the  individual 
standards  referenced  are  those  specified  by  ISO/OSI,  but  they  also  draw  on  IEEE  and 
CCITT  standards.  The  reasons  for  the  differences  between  the  two  protocol  suites 
are  the  diverse  environments  in  which  each  is  to  work:  MAP  in  a  factory 
environment.  TOP  in  an  office  environment.  Both  suites  of  protocols  provide  various 
options  at  the  individual  layers  to  provide  the  user  with  flexibility  in  meeting 
application-unique  requirements  and  environment  concerns.  Both  MAP  and  POP 
are  user-driven  initiatives  that  are  committed  to  the  use  of  existing  standards. 
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Neither  suite  is  developing  new  standards.  Both  suites  will  be  expanded, 
particularly  at  the  Application  and  Presentation  Layers,  as  new  standards  are 
developed  and  accepted  in  the  international  community.  A  joint  user/vendor  group 
has  been  formed  to  propagate  and  expand  the  two  standards  and  to  provide  a  forum 
for  both  vendor  inputs  and  user  concerns.  This  group,  called  the  MAP/TOP  User 
Group,  is  located  at  One  SME  Drive,  P.O.  Box  930,  Dearborn,  Mich.,  48121. 

The  primary  sponsor  of  MAP  has  been  the  General  Motors  Corporation,  whose 
factory  communications  needs  were  not  being  satisfied  by  the  communications 
industry.  They  require  support  of  the  concept  of  flexible  automation,  which  enables 
a  single  manufacturing  facility  to  produce  a  variety  of  different,  constantly  changing 
products  through  changes  in  programming.  With  flexible  automation,  companies 
can  respond  rapidly  to  varied  market  needs,  design  changes,  and  product  customi¬ 
zation.  These  communications  needs  are  unique  to  the  factory  environment,  and 
MAP  has  been  put  in  place  to  satisfy  them.  Simply,  MAP  is  a  set  of  rules  for  data 
communications  among  devices  made  by  different  vendors,  optimized  for  the  needs  of 
factory  automation,  communications,  and  control.  MAP  can  be  thought  of  as  a 
specialized  implementation  of  the  OSI  Model,  specifically  configured  for  factory 
automation.  Table  3-1  illustrates  the  MAP  Version  3.0  architecture  according  to  the 
OSI  Seven  Layer  Model. 

The  primary  sponsor  of  TOP  has  been  the  Boeing  Computer  Services  Company. 
This  protocol  suite  is  designed  to  operate  in  an  office  environment,  linking  such 
equipment  as  word  processors,  PCs,  and  computer  mainframes.  Applications  that 
are  to  be  supported  include  electronic  mail,  word  processing,  editable  text  and 
nontext  document  exchange,  graphics  interchange,  and  file  transfer.  TOP  has 
increased  the  functionality  of  their  specification  by  adding  various  data  exchange 
standards  to  accommodate  the  transmission  and  representation  of  certain  types  of 
data.  Table  3-2  illustrates  the  TOP  Version  3.0  architecture  according  to  the  OSI 
Seven  Layer  Model. 

3.1.1  MAP/TOP  Architecture  Comparison  -  Shared  Standards 


As  Tables  3  1  and  3-2  show,  MAP  and  TOP  duplicate  each  other  exactly  at  the 
Presentation,  Session,  Transport,  Network,  and  Data  Link  Layers.  This  subsection 
is  concerned  with  the  application  protocols  common  to  both  suites. 
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TABLE  3-1 


MANUFACTURING  AUTOMATION  PROTOCOL 
(MAP  Version  3.0) 


Layer 

Standard 

Physical 

Broadband  Token  Bus  (10  Mbps) 

Carrierband  Token  Bus  (5  Mbps) 

Data  Link 

IEEE  802.4  Token  Passing  Media  Access 

IEEE  802.2  Class  1  (Connectionless  Link  Level  Control) 

Network 

ISO  Connectionless  Network  Service  (CLNS-Datagram) 

End  System  to  Intermediate  System  (ES-to-IS)  Routing  Exchange  Protocol 

Transport 

ISO  Transport  Protocol  Class  4  (TP-4)  Service 

Session 

ISO  Full  Set 

Presentation 

ISO  Abstract  Syntax  Notation  (ASN  1 ) 

Application 

ISO  File  Transfer,  Access,  and  Management  (FTAM) 

EIA  RS-51 1  Manufacturing  Message  System  (MMS) 

ISO  Associative  Control  Service  Elements  (ACSE) 

ISO  Common  Management  Information  Protocol  (CMIP) 

ISO  Network  Directory  Services 

Note:  PVIbps  =  megabits  per  second;  IEEE  =  Institute  of  Electrical  and  Electronic  Engineers:  ISO  =  International 
Standards  Organization;  EIA  =  Electronic  Industries  Association 


3. 1.1.1  Data  Link  Layer 

The  common  data  link  protocol,  IEEE  802.2  Logical  Link  Control  Class  1 
(LLC  1),  provides  a  connectionless-oriented  communication  service  that  allows  for 
exchange  of  data  between  two  logical  entities  without  establishment  of  a  connection. 
It  does  not  provide  for  message  sequencing,  acknowledgment,  flow  control,  or  error 
recovery.  The  use  of  802.2  LLC  1  and  an  appropriate  bridge  allows  the  connection  of 
two  LANs.  Use  of  this  connection  scheme  requires  that  all  node  addresses  on  both 
LANs  be  unique. 

3. 1. 1.2  Network  Layer 

At  the  Network  Layer,  both  LANs  use  the  End  System  to  Intermediate  System 
(ES-to-IS)  routing  exchange  mechanism  to  provide  a  dynamic  routing  capability. 


TABLE  3-2 


TECHNICAL  AND  OFFICE  PROTOCOL 
(TOP  Version  3.0) 


Layer 

Standard 

Physical 

Baseband  Bus  ( 1 0  Mbps) 

Broadband  Bus  ( 1 0  Mbps) 

Carrierband  (5  Mbps) 

Shielded  Twisted  Pair  (4  Mbps) 

Data  Link 

IEEE  802.3  CSMA/CD  Media  Access 

IEEE  802.4  Token  Bus  Media  Access 

IEEE  802.5  Token  Ring  Media  Access 

IEEE  802.2  Class  1  (Connectionless  Link  Level  Control) 

CCITT  Link  Access  Protocol  Balanced  (LAPB) 

Network 

CCITT  X  25  Packet  Level  Protocol  (PLP) 

ES-to-IS  Routing  Exchange  Protocol 

ISO  Connectionless  Network  Service  (CLNS-Datagram) 

Transport 

ISO  Transport  Protocol  Class  4  (TP-4)  Service 

Session 

ISO  Full  Set 

Presentation 

ISO  Abstract  Syntax  Notation  (ASN  1) 

Application 

ISO  File  Transfer,  Access,  and  Management  (FTAM) 

ISO  Associative  Control  Service  Elements  (ACSE) 

CCITT  X.400  Message  Handling  System  (MHS) 

ISO  Virtual  Terminal  Protocol  (VTP  Basic  Class) 

ISO  Common  Management  Information  Protocol  (CMIP) 

ISO  Network  Directory  Services 

Note:  Mbps  =  megabits  per  serond,  IEEE  =  Institute  of  Electrical  and  Electronic  Engineers.  CSMA(CD  =  Garner 
Sense  Multiple  Access  with  Collision  Detection,  ES-to-IS  =  End  System  to  intermediate  System,  iSO  =  international 
Standards  Organization 


The  ES-to-IS  routing  mechanism  can  be  considered  a  sublayer  within  the  ISO 
Connectionless  Network  Service  (CLNS)  Protocol,  which  is  used  to  provide 
interoperability  within  a  concatenated  networking  environment.  This  protocol  is 
used  to  connect  more  than  two  LANs  together  or  to  connect  with  a  wide-area 
network  (WAN).  The  standard  used  to  support  long-haul  connectivity  is  the 
CCITT  X.25  Packet  Level  Protocol  (PLP)  with  the  Link  Access  Protocol  Balanced 
(LAPB)  at  the  Data  Link  Layer.  Connection  to  an  X.25  WAN  requires 


implementation  of  the  Subnetwork  Dependent  Convergence  Protocol  (SNDCP) 
between  CCITT  X.25  and  the  ISO  CLNS  protocols. 

3.1. 1.3  Transport  Layer 

The  common  transport  protocol,  ISO  Transport  Protocol  Class  4  (TP-4),  is  a 
connection-oriented  protocol  that  assumes  the  use  of  an  unreliable,  underlying 
network  service.  TP-4  provides  the  transport  service  with  multiplexing,  error 
detection,  and  error  recovery.  Specifically,  TP  4  service  makes  sure  that  data  is  not 
lost,  duplicated,  or  corrupted  in  transit  and  that  it  arrives  at  its  destination  in  the 
right  order.  TP-4  has  end-system-to-end-system  significance,  where  each  end  is 
defined  as  a  corresponding  transport  entity.  TP-4  is  functionally  equivalent  to  DoD 
TCP. 

3. 1. 1.4  Session  Layer 

The  common  session  protocol,  ISO  Full  Session,  provides  a  means  for 
cooperating  presentation  entities  to  organize  and  synchronize  their  conversation  and 
to  manage  the  data  exchange.  ISO  has  defined  three  subsets  of  the  12  functional 
units  that  make  up  the  full  session  protocol;  the  Basic  Combined  Subset  (BCS), 
Basic  Synchronized  Subset  (BSS),  and  Basic  Activity  Subset  (BAS).  Different 
subsets  are  required  by  different  application  protocols. 

3. 1. 1.5  Presentation  Layer 

The  common  presentation  protocol.  Abstract  Syntax  Notation  (ASN  1). 
specifies  rules  for  defining  and  recording  the  meaning,  or  semantic  content,  of 
messages. 

3. 1. 1.6  Application  Layer 

Both  protocol  suites  specify  use  of  the  Associative  Control  Service  Elements 
(ACSE).  There  are  two  parts  to  ACSE  —  the  Common  Application  Service  Elements 
(CASE),  which  provide  general  use  capabilities  needed  by  nearly  all  applications, 
and  the  Specific  Application  Service  Elements  (SASE),  which  provide  services  to 
specific  applications. 

The  FTAM  protocol  is  also  specified  by  both  suites.  E'l'AM  is  logically  divided 
into  two  sections.  The  first  section,  file  transfer  protocol,  deals  primarily  with  the 
way  a  file  is  moved  from  one  system  to  another.  The  second  section,  file  access  and 


management,  deals  with  file  attributes  and  protection.  The  FTAM  protocol  provides 
for  the  transfer  of  data  files  in  a  manner  that  is  transparent  to  the  semantics  of  that 
file.  This  means  that  although  FTAM  knows  nothing  about  contents,  it  can  be  used 
to  transfer  files  between  systems.  Both  suites  also  share  the  Common  Management 
Information  Protocol  (CMIP)  specification  and  the  Network  Directory  Services 
specification.  The  two  major  components  of  OSI  management  are  Systems 
Management  and  Layer  Management.  Systems  Management  deals  with  the  control, 
monitoring,  etc.,  of  multiple  layers.  Layer  Management  deals  with  the  control, 
monitoring,  etc.,  of  a  single  layer.  The  CMIP  is  designed  to  provide  the  total  Systems 
Management  function.  Additional  protocols  to  provide  the  Layer  Management 
functions  are  being  developed. 

3.1.2  MAP/TOP  Architecture  Comparison  -  Differing  Standards  and  Options 

This  subsection  discusses  the  differences  and  the  options  provided  by 
MAP/TOP  at  several  of  the  layers. 

3. 1.2. 1  Physical  Layer 

The  backbone  MAP  Physical  Layer  is  a  radio  frequency  broadband  bus 
providing  high  immunity  to  radio  frequency  and  electromagnetic  interference 
caused  by  the  types  of  machinery  located  on  the  factory  floor,  ease  of  reconfiguration, 
which  can  be  accomplished  without  adding  additional  cable,  and  suitability  for 
campus  sized  LANs  spanning  several  miles.  The  bandwidth  provided  by  the 
broadband  bus  is  analogous  to  that  of  cable  television,  which  can  simultaneously 
handle  dozens  of  difierent  television  signals.  This  type  of  medium  uses  frequency 
division  multiplexing  to  divide  the  total  bandwidth  (approximately  400  Mbps),  into 
separate  channels  to  accommodate  the  various  types  of  traffic.  The  MAP 
specification  calls  for  two  data  channels  operating  over  the  broadband  medium,  each 
operating  at  10  Mbps.  To  accomplish  this  type  of  simultaneous  medium  operation, 
all  stations  must  use  either  a  frequency  agile  or  fixed  frequency  type  of  radio 
frequency  (RF)  modem  to  gain  access  to  the  physical  medium.  These  strengths,  plus 
the  fact  that  there  is  a  need  within  the  factory  environment  to  transmit  various 
types  of  information  (e.g.,  video,  data,  voice)  over  the  same  medium  at  the  same  time, 
make  it  the  perfect  medium  for  use  in  the  factory  environment. 

The  MAP  architecture  also  provides  for  use  of  Carrierband,  which  is  a  .')  Mbps 
token  passing  bus.  This  is  a  less  expensive  way  to  link  terminals  and  other  devices 


located  in  a  single  work  group  or  cell.  Carrierband  is  similar  to  the  IEEE  802.3 
standard  in  that  it  uses  the  entire  bandwidth  of  the  cable  when  transmitting  data, 
but  differs  in  the  media  access  method,  i.e.,  token  passing  vs.  CSMA/CD. 
Carrierband  is  less  expensive  because  it  does  not  require  use  of  relatively  expensive 
RF  modems  or  a  headend  remodulator  as  do  broadband  systems. 

TOP  initially  specified  a  digital  baseband  bus  as  its  physical  media  standard; 
with  Version  3.0,  other  choices  were  added.  A  baseband  bus  is  used  to  transmit 
primarily  data  traffic  and  provides  only  one  transmission  channel  at  a  time. 
Baseband  media  provide  a  data  rate  of  10  Mbps  limited  to  500  meter  network 
segments  and  a  maximum  of  1,025  nodes.  This  type  of  medium  is  generally  favored 
for  the  office  environment  because  the  capacity  to  handle  multiple  channels  is 
frequently  not  required  and  would  be  prohibitively  expensive.  The  TOP  users  group 
acknowledges  that  the  selection  of  transmission  media  at  the  Physical  Layer  is  based 
on  user  requirements  and  has  specified  implementation  specifications  to  accom¬ 
modate  various  types  of  cables  to  meet  user  requirements. 

The  other  physical  media  standards  that  are  specified  are  MAP’s  Broadband 
(10  Mbps)  and  Carrierband  (5  Mbps)  standards,  as  well  as  shielded  twisted-pair  wire 
(4  Mbps),  which  is  used  in  IEEE  802.5  token  ring  networks. 

The  costs  associated  with  broadband  and  baseband  are  directly  related  to  the 
bandwidth  that  each  provides.  A  generalization  can  be  made  that  the  broadband 
method  is  about  2  to  2^  times  more  expensive  than  its  baseband  counterpart  because 
of  the  RF  modems,  headend  remodulator,  and  physical  cable  plant  required. 
Moreover,  maintenance  costs  and  maintenance  staffing  requirements  pertaining  to 
the  broadband  network  are  more  expensive  and  more  difficult.  The  selection  of  a 
physical  medium  is  dependent  on  the  specific  application  and  environment.  The 
decision  regarding  physical  media  depends  on  such  factors  as  the  number  of 
nodes/terminals  that  have  to  be  supported,  the  distances  that  must  be  spanned  by 
the  network,  transmission  speed  and  volume  requirements,  and  environmental 
concerns. 

3. 1.2.2  Media  Access  Control 

A  second  difference  between  the  two  protocol  suites  is  in  the  choices  available 
to  provide  media  access  control.  .Vledia  access  control  specifies  how  the  individual 
stations  on  the  physical  network  may  gain  access  to  the  backbone  media.  .MAP  uses 


the  IEEE  802.4  token-passing  method,  in  which  permission  to  use  the  network  is 
passed  from  station  to  station  in  a  predetermined  order.  The  MAP  network  is 
therefore  deterministic,  because  it  guarantees  access  to  the  network  by  every  station 
within  a  predictable  period.  This  deterministic  access  capability  is  important  in  the 
factory  environment,  where  critical  data  regarding  the  status  of  a  factory  operating 
robotic  device  might  have  to  be  reported  to  a  control  program  in  an  absolutely 
predictable  manner. 

TOP  initially  specified  the  CSMA/CD  method  to  gain  access  to  the  physical 
network  media.  With  Version  3.0,  the  TOP  users  group  has  added  the  IEEE  802.4 
token  bus  passing  media  access  protocol  and  the  IEEE  802.5  token  ring  passing 
media  access  protocol.  CSMA/CD  is  a  contention  access  method  where  each  station 
on  the  bus  contends  for  the  physical  medium,  so  that  access  to  the  network  by  a 
specific  station  cannot  be  guaranteed  within  a  certain  time  period.  With  the 
CSMA/CD  access  scheme,  a  station  that  wishes  to  transmit  data  listens  to  the 
medium  to  find  out  whether  it  is  in  use;  if  it  is,  the  station  does  not  transmit.  If  the 
medium  is  not  in  use,  the  station  transmits  its  data  and  monitors  the  medium  to 
detect  a  collision  of  its  data  with  that  of  another  station.  If  a  collision  is  detected,  the 
station  backs  off  for  a  preset  time  and  then  attempts  retransmission.  The  main 
reason  for  choosing  the  IEEE  802.3  CSMA/CD  in  the  first  place  is  that  it  allows  easy 
migration  from  an  existing  installed  base  of  Ethernet  LANs  and  that  network 
components  developed  for  Ethernet  networks  are  widely  available.  In  addition,  the 
CSMA/CD  technology  running  on  the  10  Mbps  cable  has  proven  capable  of  handling 
a  variety  of  technical  and  office  applications,  from  document  exchange  to  graphics 
exchange,  in  both  business  and  engineering. 

Comparison  of  the  two  types  of  media  access  methods  —  i.e.,  MAP’s  token 
passing  deterministic  and  TCP’s  CSMA/CD  contention  schemes  —  is  appropriate. 
Trafiic  load  characteristics  have  a  heavy  influence  on  the  selection  of  a  specific 
media  access  technique.  Generally,  deterministic  protocols,  those  used  with  MAP. 
are  better  suited  for  heavy  traffic  loads  than  the  contention  based  probabilistic 
protocols  used  with  TOP.  Deterministic  protocols  allocate  the  available  bandwidth 
more  efficiently  by  giving  each  station  predetermined  access  to  the  medium.  When 
traffic  loads  are  light,  however,  deterministic  protocols  provide  individual  stations 
with  slower  response  and  less  throughput  in  comparison  with  contention-based 
probabilistic  protocols.  The  reason  for  the  slower  response  is  that  stations  have  to 


wait  their  turn,  even  though  no  other  station  may  have  anything  to  transmit.  The 
smaller  throughput  results  from  limitations  on  the  amount  of  data  a  station  may 
send  before  it  has  to  relinquish  access  to  the  medium. 

Probabilistic  protocols  have  the  opposite  traffic-handling  characteristics.  They 
behave  poorly  under  heavy  traffic  loads  because  transmission  bandwidth  is  wasted 
by  stations  contending  for  the  medium;  the  result  is  an  increase  in  the  number  of 
collisions.  But,  under  light  traffic  loads,  they  provide  stations  with  quicker  response 
and  higher  throughput  than  deterministic  protocols.  Quicker  response  is  possible 
because  stations  may  access  the  medium  immediately  whenever  it  is  idle.  Higher 
throughput  results  from  the  ability  to  access  the  medium  quickly,  over  and  over 
again,  without  the  delay  inherent  in  a  token  passing  deterministic  scheme. 
Probabilistic  access  methods  are  more  suited  for  the  random,  bursty,  unpredictable 
traffic  common  in  the  office  environment.  A  great  deal  of  debate  is  going  on  in  the 
industry  regarding  the  percentage  of  traffic  load  that  would  cause  the  probabilistic 
media  access  method  to  degrade  in  performance.  Generally,  it  is  agreed  that 
degradation  occurs  when  between  60  and  90  percent  of  the  capacity  is  being  used. 
Selection  of  media  access  protocol  is  thus  dependent  on  the  user’s  specific  application 
and  environment. 

3. 1.2.3  Application  Layer 

The  third  major  difference  pertains  to  specific  standards  chosen  at  the 
Application  Layer  of  the  OSI  Model.  The  two  protocol  suites  differ  in  the 
specification  of  the  standard  that  pertains  to  the  handling  of  message/electronic  mail 
traffic  between  stations  on  the  network.  The  MAP  architecture  specifies  the 
Manufacturing  Message  System  (MMS),  which  is  designed  to  be  a  real-time  system, 
used  to  control  and  monitor  programmable  controllers  and  other  intelligent  factory 
devices.  There  are  a  wide  variety  of  such  intelligent  devices  operating  in  the  modern 
factory,  and  the  goal  of  MMS  is  to  make  them  work  as  a  team,  to  produce  high- 
quality  products  at  minimal  cost. 

TOP  uses  the  CCITT  X.400  Message  Handling  System  (MHS),  which  is 
designed  to  support  interoperability  between  office  equipment  and  electronic  mail 
systems  in  a  store  and  forward  manner.  The  TOP  specification  also  includes  an 
additional  application  protocol,  i.e.,  ISO  VTP.  The  VTP  specified  by  TOP  is  the  ISO 
Basic  Class  Virtual  Terminal  Service/Protocol.  This  standard  is  built  around  an 


object-based  model  that  represents  a  terminal  as  a  collection  of  arrays.  Each  array 
element  may  contain  a  single  element.  This  Basic  Class  VTP  provides  only  a 
command-line  type  of  capability  with  simple  scrolling  and  is  analogous  to  the  DoD 
TELNET  protocol.  VTP  is  expected  to  be  enhanced  to  accommodate  forms-type 
applications  in  the  future. 

3. 1.2.4  TOP  Data  Exchange  Standards 

In  addition  to  the  common  network  services  represented  by  the  OSI  Model, 
TOP  specifies  several  common  data  interchange  formats  in  its  Version  3.0 
specification.  To  accommodate  the  types  of  vector  graphics  data  used  in  CAD  and 
CAM  environments,  TOP  specifies  the  use  of  IGES  Version  3.0.  This  specification 
defines  a  format  for  creation  of  a  file  that  enables  the  data  in  commercially  available 
CAD/CAM  systems  to  be  exchanged  or  archived.  IGES  Version  3.0  offers  increased 
capability  in  both  geometry  and  nongeometry  data  exchange.  The  applications  of 
printed  wiring  boards,  finite  element  models,  and  mechanical  products  are 
supported.  Another  standard  that  TOP  has  specified  is  CGM.  CGM  is  an  ANSI 
standard  for  transporting  graphics  pictures  among  different  devices.  CGM  is 
designed  to  accommodate  graphics  representations  that  do  not  require  the  d->tailed 
product  data  information  of  an  engineering  drawing.  The  CCITT  Group  4  standard 
is  specified  to  handle  raster  images  and  facsimile-type  pictures.  The  Office 
Document  Architecture  (ODA)  and  Office  Document  Interchange  Format  (ODIF)  are 
also  specified.  ODA/ODIF  are  a  family  of  standards  for  the  interchange  of  office 
documents,  such  as  memos,  reports,  letters,  and  forms.  Graphics  Kernel  System 
(GKS)  is  specified  as  the  graphics  language  standard.  GKS  is  a  two  dimensional 
language  and  can  handle  both  raster  and  vector  graphics. 

TOP  has  indicated  that  future  work  includes  FDDI  and  ISDN  at  the  Physical 
Layer,  as  well  as  Distributed  Transaction  Processing  and  forms  class  of  the  VTP 
protocol  at  the  Application  Layer.  In  the  data  format  exchange  area,  SGML,  PDES, 
Electronic  Data  Interface  (EDI),  and  standards  for  imaging  are  planned.  TOP  will 
also  address  the  Remote  Database  Access  area  as  well  as  the  security  issue. 

3. 1.2.5  CALS  Use  ofMAPITOP 

MAP  and  TOP  are  emerging  as  the  protocol  standards  that  will  be  used  in  their 
respective  environments  to  provide  interoperability  among  networked  devices.  MAP 
and  TOP  are  designed  to  connect  with  one  another.  This  is  accomplished  in  the  local 


environment  at  the  Network  Layer  that  is  common  to  both  architectures  and  resides 
above  the  media  access  protocols. 

Both  suites  were  initially  developed  for  the  local  environment,  but  TOP 
Version  3.0  includes  the  CCITT  X.25  standard  to  accomplish  long-haul  connectivity. 
The  TOP  specification  includes  the  X.25  PLP  at  the  Network  Access  Layer  and 
LAPB  at  the  Data  Link  Layer.  Note  that  both  the  MAP  and  TOP  protocol  suites  use 
the  ISO/OSI  standards  at  the  upper  layers  and  not  the  DDN  suite  of  protocols.  The 
two  protocol  suites  are  not  capable  of  interoperation.  This  means  that  the  end  points 
involved  in  the  conversation  must  apply  the  same  standards.  It  is  possible  to  link  a 
MAP  or  TOP  implementation  with  a  peer  MAP  or  TOP  implementation  over  DDN,  if 
DDN  is  used  as  a  backbone  medium  only  and  there  is  no  requirement  to  gateway 
among  the  various  segments  of  DDN.  This  can  be  accomplished  without  significant 
problems  and  requires  only  a  gateway  at  the  Network  Layer.  To  meet  the 
packetizing,  addressing,  buffering,  and  flow  control  requirements,  an  X.25  network 
access  interface  would  have  to  be  acquired.  To  interoperate  over  the  entire  DDN 
internet,  including  all  the  network  segments,  the  ISO  Internet  Protocol  must  coexist 
with  the  DoD  IP  and  be  recognized  by  the  gateway  PSNs.  To  gateway  between  the 
MAP/TOP  protocol  suites  and  the  DoD  protocol  suite,  (e.g.,  DoD  FTP  to/from  OSI 
FTAM  protocol)  would  require  considerable  work.  NBS  is  working  on  such  an 
application  protocol  gateway. 

Another  consideration  in  the  transmission  of  data  from  one  MAP  or  TOP 
implementation  over  DDN  to  another  MAP  or  TOP  implementation  is  the 
bandwidth  disparity  between  the  two  transport  media.  The  DDN  is  made  up  of 
56  kbps  backbone  links  with  either  9.6  or  56  kbps  subscriber-access  links;  the 
MAP/TOP  transport  mechanism  operates  at  megabit-per-second  speeds.  To  transfer 
the  typical  graphical  image,  in  the  million-byte  range,  over  the  DDN  packet¬ 
switching  network  would  take  considerable  time. 

3. 1.2.6  Standardization  and  Testing 

Another  problem  that  must  be  addressed  has  do  to  with  implementation  of  the 
various  protocols  by  the  vendors.  Both  the  MAP  and  TOP  architectures  are 
implementation  specifications  for  the  various  ISO  and  other  standard  protocols  that 
have  been  selected  to  support  communications  in  their  environments.  The  specific 
implementation  specifications  are  based  on  the  NBS  OSI  Implementors  Workshop 


Agreement  documents.  Centralized  testing  facilities  have  to  be  put  in  place  to  verify 
that  a  vendor  implementation  follows  the  standard  and  that  it  can  interoperate  with 
other  vendor  implementations. 

One  step  toward  establishment  of  a  testing/demonstration  system  for  OSI 
conformance  is  the  OSINET.  OSINET  is  a  WAN,  based  on  X.25  packet-switching 
technology  designed  to  help  foster  the  development  and  testing  of  OSI  products  and 
services.  AT&T’s  Accunet  X.25  packet  network  is  currently  used  as  the  OSINET 
backbone.  Vendors  will  have  to  perform  interoperability  testing  with  five  other 
OSINET  participants  to  demonstrate  conformance. 

Two  other  organizations  are  involved  in  putting  testing  and  conformance 
facilities  into  place.  The  Corporation  for  Open  Systems  (COS),  which  is  new  to  the 
community  of  standards,  is  now  developing  test  cases  and  establishing  a  test  bed  for 
the  MHS  and  FTAM  protocols.  The  Industrial  Technology  Institute  (ITI)  has  become 
the  testing  organization  for  the  MAP/TOP  user  group  and  offers  test  services  and 
test  development  for  the  protocol  suites  through  its  Network  Evaluation  and  Test 
Center  (NETC).  The  work  of  these  two  organizations  should  greatly  accelerate  the 
acceptance  and  use  of  the  new  protocol  suites. 

3. 1.2,7  Future  of  MAPITOP  to  CALS 

In  conclusion,  the  TOP  architecture  specification  is  more  applicable  to  the 
types  of  data  transmission  required  to  support  the  CALS  projects.  Figure  3-1,  based 
on  material  received  from  the  Boeing  Computer  Services  Company,  depicts  areas  of 
commonality  between  TOP  3.0  and  CALS,  and  between  TOP  3.0  and  GOSIP. 
(GOSIP  is  discussed  in  the  next  subsection.)  The  TOP  specification  has  —  or  plans  to 
provide  —  all  the  protocol  implementation  specifications  required  to  support  the 
CALS  projects.  The  10  Mbps  baseband  physical  media  with  the  CSMA/CD  media 
access  control  mechanism  should  be  sufficient  to  accommodate  the  CALS  projects  in 
the  local  environment.  This  takes  into  consideration  the  cost  of  the  physical  media 
and  the  bursty  type  of  traffic  load  that  is  anticipated  in  the  CALS  environment. 
Although  the  baseband  Physical  Layer  is  recommended  in  most  cases,  broadband 
coax  cable  may  be  appropriate  for  campus-type  installations  where  there  is  a 
requirement  to  support  a  mix  of  communications  over  longer  distances  or  where 
additional  bandwidth  is  required  to  support  the  data  volume.  In  this  case,  the 
assignment  of  specific  data  subchannels  over  the  broadband  channel  can 


accommodate  CALS-related  projects  data  transmission  requirements.  This  is 
accomplished  by  means  of  the  broadband  version  of  IEEE  802.3  and  the  appropriate 
medium  attachment  units.  The  selection  of  the  physical  medium  is  a  site-dependent 
concern  that  must  be  addressed  by  the  various  CALS  projects. 

Adoption  of  this  architecture  will  enable  the  Services  to  interface  with  industry 
when  TOP  becomes  widely  accepted  in  the  private  sector.  MAP-  and  TOP- 
compatible  products  will  start  to  become  widely  available  in  1987  —  89.  Most  vendors 
have  indicated  support  for  the  two  protocol  suites,  and  several  are  already 
introducing  products  that  conform  to  the  MAP/TOP  specifications.  Thus,  use  of  TOP 
is  a  solution  for  CALS  for  the  mid  term,  meaning  in  1  to  3  years. 

3.2  GOVERNMENT  OPEN  SYSTEMS  INTERCONNECTION  PROFILE 

We  have  reviewed  the  GOSIP  document  to  determine  its  relevance  in  support 
of  CALS  projects.  The  document  specifies  a  set  of  OSI  and  other  standard  protocols 
that  will  be  used  in  Government  procurement  documents  in  FY87  and  FY88.  The 
GOSIP  document  is  based  on  the  Implementation  Agreements  for  OSI  Protocols, 
NBS  document  NBSIR  86-3385.  GOSIP  addresses  the  need  of  the  Federal 
Government  to  move  immediately  to  multivendor  connectivity  and  provides 
specifications  for  both  end  and  intermediate  systems. 

3.2.1  GOSIP  Architecture 

Table  3-3  depicts  the  overall  GOSIP  architecture.  GOSIP  provides  various 
options  at  the  lower  layers  to  support  both  the  local  and  long-haul  environment.  For 
a  particular  procurement,  the  Government  will  select  the  appropriate  options  based 
on  the  specific  environment.  GOSIP  specifies  use  of  either  IEEE  802.3  (CSMACD) 
or  IEEE  802.4  (Token  Bus)  for  media  access  in  the  local  area.  The  IEEE  802.2  LLC  1 
data  link  protocol  is  specified  at  the  Data  Link  Layer.  The  CCTIT  X.25  PLP  is 
specified  for  use  in  the  long-haul  environment. 

The  intermediate  protocols  specified  are  those  endorsed  by  OSI:  CLNS,  TP  4. 
Session  Protocol,  Presentation  Protocol  ASN  1,  and  ACSE. 

Two  application  protocols  are  specified,  the  FTAM  protocol  and  MHS  .\.4()(). 
The  FTAM  protocol  provides  for  transfer  of  data  files  in  a  manner  that  is  transpatamt 
to  the  semantics  of  that  file.  This  means  that,  although  PTA.M  knows  nothing  about 
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FIG.  3-1 .  TOP  3.0/CALS/GOSIP  COMMON  AREAS 
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TABLE  3-3 


GOSIP  ARCHITECTURE 


Layer 

Standard 

Physical 

Baseband  Bus  ( 1 0  Mbps) 

Broadband  Token  Bus  (10  Mbps) 

Data  Link 

IEEE802  3CSMA/CDMAC 

IEEE  802.4  Token  Bus  MAC 

IEEE  802  2  Logical  Link  Control 

HDLC/LAPB 

Network 

ISO  Connectionless  Network  Service  (CLNS-Datagram) 

CCITT  X.25  Packet  Level  Protocol  (PLP) 

Transport 

ISO  Transport  Protocol  (TP  Class  4  or  Class  0  Service) 

Session 

ISO  Full  Set  of  Functional  Units 

Presentation 

NBS-AS3  Abstract  Syntax  Notation  (ASN  1 ) 

Application 

ISO  Associative  Control  Service  Elements  (ACSE) 

ISO  File  Transfer,  Access,  and  Management  (FTAM) 

CCITT  X.400  Message  Handling  System  (MHS) 

Note:  Mbps  =  megabits  per  second,  CSMA/CO  =  Carrier  Sense  Multiple  Access  with  Collision  Detection;  MAC  = 
Media  Access  Control;  HDLC/LAPB  =  High-Level  Data  Link  Control/Link  Access  Protocol  Balanced;  iSO  =  international 
Standards  Organization,  CCITT  =  Consultative  Committee  on  international  Telephony  and  Telegraphy 


contents,  it  can  transfer  files  between  systems.  FTAM  thus  becomes  the  mechanism 
to  transfer  both  text  and  graphics  data  between  CALS  systems. 

The  GOSIP  specification  is  closely  aligned  with  similar  industry  specifications 
for  open  systems,  namely  MAP  and  TOP.  The  GOSIP  specification  is  a  proper  subset 
of  the  TOP  specification.  The  differences  between  TOP  and  GOSIP  are  minimal 
within  the  basic  OSI  Seven  Layer  Model.  GOSIP  does  not  specify  the  options  of 
Carrierband  or  shielded  twisted-pair  at  the  Physical  Layer  or  the  use  of  the 
IEEE  802.5  token  ring  media  access.  Nor  does  GOSIP  specify  use  of  the  ES  to  IS 
routing  exchange  mechanism,  which  provides  dynamic  routing  and  is  thus  limited  to 
static  routing.  In  the  application  area,  GOSIP  does  not  specify  the  VTP,  CMIP.  or 
network  directory  services.  NBS  has  taken  a  conservative  approach  on  what  is 
specified  in  GOSIP  to  allow  flexibility  in  procurements.  It  is  the  plan  of  the  GOSIP 


committee  to  adopt  additional  application  and  presentation  protocols  as  they  become 
available. 

3.2.2  GOSIP  Implementor  Concerns 

The  GOSIP  document  indicates  areas,  other  than  selection  of  applicable 
protocols,  that  have  to  be  addressed  before  procurement.  These  areas  have  to  do  with 
additional  requirements  that  are  application  or  environment-specific.  Two  major 
areas  must  be  addressed:  site-dependent  performance  requirements  and  Service 
interface  requirements.  GOSIP  does  not  cite  performance  criteria.  Any  performance 
criteria  or  benchmarking  criteria  used  to  validate  performance  are  to  be  specified  by 
the  Government  Acquisition  Authority.  And  GOcalP  does  not  recognize  or  specify 
any  testing  service  for  validating  conformance  with  the  implementation  specifica¬ 
tion.  COS  may  perform  this  testing  role  beginning  in  1988.  Conformance  testing 
criteria  and  methodology  are  now  to  be  specified  by  the  Acquisition  Authority. 
Service  interface  specifications  are  required  to  integrate  user  applications  with  the 
various  layers  and  to  provide  operator  control  and  management.  Interfaces  are 
important  at  the  Network  and  Transport  Layers.  These  are  needed  to  implement  the 
specification  and  to  provide  the  Services  with  a  usable  and  efficient  system. 

3.2.3  CALS  Use  of  GOSIP 

The  current  GOSIP  document  is  a  significant  step  toward  interoperability 
between  the  Government  and  industry.  It  should  help  to  focus  the  market  by 
informing  vendors  exactly  what  is  required  by  the  Government.  Although  the 
application/presentation  protocols  required  to  support  the  transfer  of  documents  and 
graphics  are  not  specified,  GOSIP  intends  to  address  these  in  1987  —  89.  The  work 
being  done  on  MIL-STD  1840  —  specifically  on  SGML,  IGES,  CCITT  Group  4,  and 
CGM  —  is  applicable  to  these  protocols  and  should  be  adopted  by  GOSIP.  The  TOP 
Version  3.0  also  addresses  the  data  exchange  protocols  required  by  CALS  projects. 
The  TOP  protocol  suite,  which  is  a  superset  of  the  GOSIP  document,  should  suggest 
the  additional  protocols  that  will  be  specified  by  GOSIP.  The  implementor  concerns, 
discussed  in  the  preceding  paragraph,  will  have  to  be  addressed  by  the  CALS 
community  to  ensure  interoperability.  The  GOSIP  document,  providing  direction  for 
implementing  all  the  protocols,  should  help  greatly  in  eliminating  the  problem  of 
vendor-specific  implementations,  which  have  been  a  barrier  to  connectivity  in  the 
past. 


High-bandwidth  support  at  the  Physical  Layer,  in  the  long-haul  environment, 
is  required  to  satisfy  the  CALS  projects’  transmission  needs.  This  requirement  will 
be  addressed  by  the  emerging  ISDN  and  FDDI  standards.  These  two  standards  are 
GOSEP  priorities  for  1988  —  89. 

3.3  T-CARRIER  SERVICES 

The  first  T-Carrier  service,  a  digital  facility,  was  introduced  into  the  hitherto 
analog  telephone  network  in  1962.  It  used  an  algorithm  called  Pulse  Code 
Modulation  (PCM)  to  digitize  voice  signals  and  enabled  24  of  these  digitized  voice 
signals  to  be  multiplexed  over  two  pairs  of  wires  by  means  of  TDM.  This  first 
service,  called  Tl,  provided  a  data  rate  of  1.544  Mbps.  It  has  since  evolved  into  what 
is  termed  the  T-Carrier  Services,  which  provides  a  hierarchy  of  increasing 
transmission  data  rates.  Tl  service  became  commercially  available  in  1983.  The  T2 
service  provides  6.312  Mbps,  the  T3  provides  44.736  Mbps,  and  the  T4  provides  a 
data  rate  of  274.176  Mbps. 

3.3.1  T-Carrier  Overview 

Tl  Carrier  service  is  a  telephone  transmission  technology  with  transmission 
over  two  pairs  of  wires.  It  was  designed  to  take  as  much  advantage  as  possible  of 
existing  analog  telephone  transmission  technology,' i.e.,  twisted-pair  wire.  Tl 
repeaters  are  designed  to  be  spaced  every  3,000  to  6,000  feet,  an  arrangement  that 
allows  for  one-for-one  replacement  of  the  existing  analog  lines’  induction  loading 
coil.  The  Tl  composite  data  rate  (1.544  Mbps)  can  be  either  used  in  its  entirety  or 
channeled.  The  most  common  channeling  scheme  divides  the  Tl  composite  into 
24  channels,  each  capable  of  carrying  64  kbps.  Each  64  kbps  channel  is  designated 
Digital  Signal  Level  0  (DSO);  and  the  entire  24-channel  composite  is  designated  DSl. 

Tl  applications  are  of  three  basic  types:  (1)  point  to  point,  (2)  drop-and-insert. 
and  (3)  networking.  Point  to  point  transmission  and  the  associated  multiplexers 
used  to  accomplish  it  provide  only  one  active  Tl  link,  and  they  transmit  inputs  only 
from  point  A  to  point  B.  Drop-and-insert  multiplexers  provide  the  capability  to 
establish  point-to-point  links  with  many  drop  points  within  the  network.  This 
allows  single-DSO  channels  to  be  removed  from  the  Tl  composite  at  intermediate 
locations  in  the  network  and  new  DSO  channels,  targeted  for  other  locations,  to  be 
added  to  the  composite. 


The  drop-and-insert  approach  is  not  recommended  for  applications  involving 
more  than  a  few  intermediate  locations  because  of  associated  technical  problems. 
Networking  multiplexers  enable  an  entire  DSl  composite  to  be  switched  as  a  whole, 
in  addition  to  making  it  possible  for  individual  DSO  channels  to  be  added  and 
extracted  from  a  composite.  To  achieve  this  networking  capability  requires  either  a 
Digital  Access  and  Cross-Connect  Service  (DACS)  from  AT&T  or  private  DACS 
switches.  With  private  DACS  switches,  users  can  use  non- AT&T  transmission 
carriers. 

Some  ancillary  features  to  look  for  in  designing  a  T1  network  are  Automatic 
Alternate  Routing  (AAR),  network  management  capabilities,  dynamic  reconfig¬ 
uration  capabilities,  and  rapid  addition  of  circuits.  In  a  small  T1  network,  e.g.,  two 
nodes  connected  point-to-point,  many  of  these  features  would  be  unnecessary.  How¬ 
ever,  in  multinode  networks,  these  features  become  much  more  important.  These 
features  add  to  the  price  of  the  equipment  at  every  node. 

Users  subscribing  to  anything  above  Tl  are  rare.  They  are  usually  handled  by 
special  construction  tariffs  between  the  local  phone  company  and  the  customer.  In 
almost  all  these  cases  the  high-speed  circuits  serve  only  to  link  the  customers 
premises  in  a  point-to-point  connection  and  do  not  pass  through  the  telephone 
company’s  central  office.  In  fact.  Data  Switch  Inc.  recently  announced  a  product  that 
allows  channel-to-channel  connection  of  IBM  mainframes  across  a  T3  pipe.  This 
would  permit  direct  connection  of  IBM  mainframes  across  virtually  unlimited 
distances  without  the  use  of  an  FEP. 

3.3.2  T-Carrier  Costs 

The  following  are  the  costs  of  recently  tariffed  AT&T  Accunet  Tl.5  (Tl)  service 
and  T45  (T3)  service.  We  assume  for  purposes  of  analysis  that  there  are  three  nodes 
with  100  miles  between  them,  and  that  there  are  24  channels  on  each  link. 


AccunetTl. 5  pricing  — 

•  Recurring  monthly  charges: 
^  Base  T1  price 


$  2,600 


k  Mileage  charge  @  $15.50  per  mile  $  1,550 


$4,212 


>  Central  office  charge 
^  Total  Monthly 
^  3  links  (total  monthly  X  3) 
•  One-time  charges: 


^  Typical  24-channel  multiplexor  $25,000 


$12,636 


►  T1  installation  charges 

►  Total  one-time 
^  3  links 


$25,620 


$76,860 


A  typical  multiplexor  in  this  price  range  would  allow  the  following:  connection  of 
geographically  dispersed  sites  using  single  T1  transmission  link,  voice,  and  data 
capabilities;  automatic  circuit  path  selection  based  on  availability  and  performance; 
dynamic  change  of  channel  rates;  dear-channel  capabilities;  and  AAR  in  the  event  of 
circuit  failure.  Prices  on  T1  multiplexing  equipment  vary  from  $5,000  to  more  than 
$  100,000,  depending  on  the  options  chosen. 

AT&T  T45  (T3)  service  pricing  (using  same  network  described  above) 


•  Monthly  charges: 
^  Base  T45  price 


$  1,400 


^  Mileage  charge  (q)  $205  per  mile  $20,500 

►  Central  office  connection  $  1,000 

►  M28  Multiplexor  from  AT&T 

^  Total  monthly  $24,600 

^  3  links  (total  monthly  X  3) 


$73,800 


•  One-time  charges: 

^  Multiplexor 
^  T45  installation  charges 
^  Total  one-time 
^  3  links 

The  M28  Multiplexor  gives  the  user  28  T1  lines.  Prices  vary  on  the  basis  of  terms 
covering  mileage  and  length  of  lease  as  follows  (commercial  rates): 

•  1  —  50  miles 


► 

1-year 

lease 

$400  +  $220  per  mile 

> 

2-year 

lease 

$400  -1-  $190  per  mile 

> 

3-year 

lease 

$400  -h  $170  per  mile 

51 

— 100  miles 

► 

1-year 

lease 

$900  -t-  $210  per  mile 

> 

2-year 

lease 

$900  +  $180  per  mile 

> 

3-year 

lease 

$900  -f  $160  per  mile 

101  +  miles 

► 

1-year 

lease 

$1,400-)- $205  per  mile 

► 

2-year 

lease 

$1,400 -l-$175  per  mile 

► 

3-year 

lease 

$1,400-1- $155  per  mile 

These  prices  assume  that  the  local  AT&T  central  office  is  equipped  to  handle  T45 
service.  For  special  services,  an  experimental  surcharge  of  $34,000  a  month  is 
added.  T45  transmission  is  guaranteed  to  be  all-fiber-optic.  Tariffs  generally  apply 
to  interstate  and  inter-LATA  ( local  access  and  transport  area)  applications.  A  single 
multiplexor  would  handle  28  T1  inputs  from  two  nodes.  Maximum  speed  on  any  one 
channel  would  be  1.544  Mbps  (Tl)  and  would  support  up  to  768  input  channels. 

The  Tl  market  has  become  highly  competitive  in  the  past  year.  This  has  led  to 
price  declines  and  the  addition  of  many  new  features  on  Tl  multiplexors.  Both  MCI 
and  U.S.  Sprint  also  offer  Tl  service.  But  local  Tl  access  provided  by  the  local 


telephone  company  is  required,  no  matter  which  long  distance  carrier  is  selected, 
and  is  not  included  in  the  T1.5  and  T45  prices  given  above. 

3.3.3  T-Carrier  Standards 

T1  will  probably  be  adopted  as  the  primary  rate  access  for  ISDN  implementa 
tions  in  the  United  States.  This  will  entail  substantial  changes  in  the  way  control 
and  signaling  is  handled  by  T1  transmission.  The  current  signaling  standard.  DSl. 
places  the  requirement  that  no  more  than  eight  consecutive  zeros  pass  through  the 
public  network.  The  public  telephone  network  loses  timing  and  synchronization  if 
this  requirement  is  not  met.  To  prevent  timing  loss,  a  "1"  bit  is  inserted  at  eight-bit 
intervals.  This  "bit-stufiing”  lowers  the  effective  data  rate  to  56  kbps  from  64  kbps 
on  each  of  the  24  T1  subchannels. 

Because  of  the  pressure  on  the  United  States  to  join  the  international  push  for 
"dear-channel,  full-64  kbps”  ISDN  standards,  both  AT&T  and  various  U.S. 
standards  organizations  are  working  on  restructuring  the  way  signaling  information 
is  carried  over  a  T1  link.  Many  new  standards  are  proposed  to  address  the 
"1”  requirement,  as  well  as  the  other  problems  that  exist  with  current  digital 
signaling  standards.  Most  of  these  specifications  have  been  proposed  by  AT&T  but, 
because  of  divestiture,  AT&T  can  no  longer  dictate  what  happens  in  the  Tl  market 
place.  Consensus  must  be  reached  by  the  regional  Bell  operating  companies 
(RBOCs)  as  well  as  the  various  standards  organizations  before  any  new  standard  can 
be  implemented.  Many  of  the  Tl  multiplexor  vendors  have  their  own  proprietary 
scheme  to  achieve  the  proper  "1”  insertion  for  transmission  over  the  public  telephone 
network.  This,  however,  forces  the  user  to  use  that  vendor’s  equipment  at  all 
terminations  of  the  network. 

Though  microwave  or  fiber  optic  transmission  schemes  may  use  the  T  Carrier 
rates,  they  do  not  use  the  transmission  technology  classically  considered  Tl.  The 
equivalent  fiber-optic  lino  type  designation  is  FT3  for  T3  (44.736  Mbps)  and  FT4  for 
T4  (274.176  Mbps).  Fiber-optic  repeaters  have  spacing  requirements  of  4  to  5  miles. 
Many  of  the  transmission  facilities  that  connect  telephone  company  central  offices 
have  been  converted  to  fiber  optics. 


3.4  INTEGRATED  SERVICES  DIGITAL  NETWORK 


ISDN  is  a  digital  communications  medium  evolving  from  the  present  —  mainly 
analog,  public,  switched  —  telephone  network.  When  fully  implemented,  it  will 
provide  end-to-end  digital  connectivity,  access  and  service  integration,  user  control 
of  services,  upward  compatibility  with  present  services,  and  a  set  of  standardized 
network  interfaces.  It  will  provide  end-to-end  connections  and  simultaneous  support 
for  digitized  voice  and  nonvoice  traffic  via  a  single  access.  It  will  allow  the  end  users 
to  change  the  usage  of  their  ISDN  interface  dynamically  at  different  times  of  the 
day.  ISDN  is  to  bring  standardization  to  the  widely  proliferating  voice  and  data 
communications  systems.  Data  communications  will  probably  surpass  voice 
communications  in  the  near  future. 

3.4.1  Integrated  Services  Digital  Network  Architecture 

ISDN  will  provide  two  broad  categories  of  service  —  Teleservices  and  Bearer. 
Teleservices  involve  the  OSI  Seven  Layer  Model’s  upper  layers,  i.e..  Transport  and 
above.  Services  to  be  provided  include  teletex,  videotext,  and  electronic  mail. 
Teleservices  are  still  being  defined  by  the  CCITT. 

Bearer  services  involve  the  lower  layers,  i.e..  Physical  through  Network,  of  the 
OSI  Model.  Two  basic  Bearer  services  will  be  offered  by  ISDN.  The  first.  Circuit 
Mode  Information,  is  64  kbps  unrestricted  digital  information  (UDI)  and  is  used  in 
such  applications  as  speech  and  audio  transmission.  Circuit  mode  also  supports 
varying  bandwidths  to  accommodate  various  types  of  data.  These  range  from 
364  kbps  to  1,920  kbps.  The  top  rate  in  European  implementations  of  ISDN  will  be 
1,920  kbps.  The  second  Bearer  service.  Packet  Mode,  provides  transfer  of  user  data 
through  either  virtual-call,  switched  circuits,  or  permanent  virtual  circuits.  Virtual- 
call  service  entails  setting  up  and  tearing  down  the  circuit  for  each  call  and  is 
analogous  to  dial-up  service.  Permanent  virtual  circuits  remain  established  until 
changed  by  a  network  administrator  and  are  analogous  to  dedicated  lines.  The 
access  protocol  for  virtual  circuit  service  is  Layer  3  of  CCITT  standard  X.2.5.  It  is  the 
user’s  responsibility  to  package  the  data;  ISDN  will  not  alter  the  data. 

There  are  two  types  of  subscriber  access  to  the  ISD.N’:  Basic  and  Primary 
Access.  The  Basic  access  consists  of  two  64  kbps  Bearer  (  B)  channels  and  one  1 6  kbps 
Delta  (D)  channel.  This  is  known  as  2B -t- D  access.  T'he  B  channel  transmits 
bidirectional  digital  voice  and/or  data  traffic;  the  D  channel  carries  signaling  for  call 


set-up,  call  clearing,  etc.  Both  the  B  and  D  channels  can  also  be  used  for  packet- 
switched  data  applications.  The  Basic  access  will  be  oriented  toward  residential  and 
small  business  subscribers.  Basic  access  will  also  be  used  to  connect  users  in  large 
organizations  to  a  central  distribution  system,  e.g.,  a  LAN  or  Private  Branch 
Exchange  (PBX). 

The  Primary  access  is  used  for  connecting  local  distribution  systems  to  ISDN. 
It  provides  a  transmission  bandwidth  of  1.544  Mbps  (Tl).  Known  as  23B-I-D,  the 
Primary  access  consists  of  23  B  channels  and  a  single  D  channel,  all  operating  at 
64  kbps.  Because  of  the  limitations  of  current  Tl  technology,  8  kbps  of  each  channel 
are  required  to  support  timing  overhead.  The  effective  throughput  of  each  64  kbps 
channel,  therefore,  is  only  56  kbps.  One  of  the  requirements  of  ISDN  is  that  all 
64  kbps  of  each  channel  be  usable  by  a  subscriber;  this  is  called  clear  channel  capa¬ 
bility. 

Higher  speed  applications,  such  as  teletex,  videotext,  and  electronic  mail  can 
be  served  via  Higher  Speed  (channels,  H  channels.  The  HO  channel  provides  a 
bandwidth  of  384  kbps;  the  Hll  channel  provides  1,536  kbps.  Various  combinations 
of  H  and  B  channels  can  be  configured  by  the  subscriber.  The  Primary  access, 
although  not  yet  approved  as  a  standard  by  the  U.S.  representative  to  CCITT,  will 
closely  resemble  AT&T’s  standard  Tl  transmission  format. 

3.4.2  integrated  Services  Digital  Network  Standards  Organization 

The  CCITT  has  primary  responsibility  for  generating  ISDN  standards  on  an 
international  level.  The  object  of  the  CCITT  is  to  establish  recommendations  for 
end-to-end  performance,  interconnection,  and  maintenance  of  international  net¬ 
works  used  for  telephone,  telegraph,  and  data  communications.  The  Office  of 
International  Communications  Policy,  under  the  Bureau  of  Economic  Affairs  within 
the  Department  of  State,  is  the  official  U.S.  representative  to  the  CCITT.  The  CCITT 
ISDN’  standards  began  with  the  Red  Book,  which  was  issued  in  1984.  The  Red  Book 
stated  the  basic  architectural  model  and  the  types  of  services  that  were  to  be  offered. 
The  next  milestone  was  the  Grey  Book  issued  in  1986.  It  contained  the  specifications 
for  Layers  1  and  2.  The  next  specification,  the  Blue  Book,  is  to  be  issued  in  1988.  It 
will  contain  the  complete  specifications  for  Layers  1,  2,  and  3. 

Many  of  the  ISDN  standard  recommendations  come  from  the  Tl  committee  (not 
related  to  the  1.544  Mbps  Tl  specification).  The  Tl  committee  develops 


interconnection  standards  for  the  U.S.  telecommunications  network.  DCA  has 
representatives  on  the  T1  committee.  The  Exchange  Carriers  Standard  Association 
(ECSA)  is  the  administrative  body  for  the  T1  committee.  The  ECSA  came  into  being 
after  the  divestiture  of  AT&T  which,  before  divestiture,  was  the  only  U.S.  standard¬ 
making  body  for  telephone  interfaces.  The  TlDl  subcommittee  is  preparing  ISDN- 
related  standards  for  submission  to  the  U.S.  CCITT  representative. 

3.4.3  Integrated  Services  Digital  Network  Status 

In  most  European  countries  there  is  only  one  telephone  company,  and  the 
standards  developed  for  ISDN  within  any  country  may  differ  from  those  developed  in 
the  United  States  or  others.  The  CCITT  is  to  make  sure  that  standards  developed  for 
inter-country  ISDNs  are  compatible.  The  TlDl  subcommittee  will  probably  approve 
circuit-mode  specifications  by  the  summer  of  1987;  and  with  compatible  products, 
will  probably  be  introduced  shortly  thereafter.  However,  true  compatibility  of  ISDN 
products  in  a  multivendor  environment  will  probably  take  2  or  3  more  years. 
Vendors  are  apprehensive  about  committing  to  something  that  will  probably  change 
in  the  future.  Most  of  the  RBOCs  are  working  on  some  kind  of  ISDN  implementa¬ 
tion.  Because  of  the  substantial  costs  associated  with  conversion  of  all  the  RBOC 
central  offices,  full  conversion  to  digital  is  not  projected  until  1990.  Furthermore, 
local  non-Bell  phone  companies  may  never  convert  to  digital.  The  Ameritech  RBOC 
recently  began  a  pilot  ISDN  project  with  McDonald’s  Corporation  in  Chicago.  At 
this  writing,  however,  there  are  no  conclusive  results  to  report.  In  another  trial 
scheduled  to  start  in  mid- 1988,  AT&T,  Shell  Oil,  and  Tenneco  Inc.  have  contracted 
with  Southwestern  Bell  to  provide  an  ISDN  network.  Most  trade  publications 
indicate  continued  testing  and  development  through  1988,  with  some  commercially 
viable  implementation  available  as  early  as  1989.  Full  ISDN  implementation  will 
probably  not  be  available  until  the  year  2000. 

Approved  tariffs  for  ISDN  services  are  not  available,  and  costs  associated  with 
converting  to  ISDN  are  unknown.  Cost  justification  for  ISDN  on  the  part  of 
subscribers  should  come  from  added  functionality  and  from  the  lowered  costs  of 
network  administration. 

One  of  the  most  important  considerations  in  implementing  an  ISDN  system  is 
its  effect  on  the  existing  installed  base  of  computer/data  processing  equipment. 


Effective  deployment  of  ISDN  will  require  terminal  adapters  to  interface  with 
existing  non-ISDN  terminal  equipment. 

3.5  FIBER-DISTRIBUTED  DATA  INTERFACE 

Three  elements  make  up  a  fiber  optic  system:  the  transmitter,  the  receiver, 
and  the  optical  cable  that  connects  them.  The  transmitter  is  a  modulated-voltage  to 
modulated-light  converter;  the  receiver  reconverts  modulated  light  to  modulated 
electrical  voltage.  Unlike  long  haul  intercity  fiber  optics  where  every  interface  is  a 
T-Carrier,  building  and  campus  fiber-optic  lines  carry  an  amalgam  of  protocols  and 
vendor-proprietary  transmission  formats.  It  is  in  this  area  where  FDDI  will  have  its 
greatest  effect.  The  FDDI  is  being  developed  by  ANSI  and  specifies  a  standard  for 
100  Mbps  serial  data  communications  over  optical  fiber.  FDDI  networks  will  be  best 
suited  for  mainframe-to-mainframe  computer  links;  for  backend,  high-performance 
transport;  and  for  networking  engineering  workstations.  The  media  access  protocol 
specified  for  FDDI  is  a  token-passing  over  physical  ring  topology  and  conforms  to  the 
structure  of  the  IEEE  802.5  standard. 

3.5.1  Fiber-Distributed  Data  Interface  Architecture 

The  FDDI  consists  of  primary  and  secondary  rings,  each  independent  of  the 
other  and  each  with  a  speed  of  100  Mbps.  This  architecture  allows  transmission  in 
opposite  directions  simultaneously,  so  that  there  is  an  effective  throughput  of 
200  Mbps.  At  present,  two  types  of  fiber  for  the  cabling  system  are  common,  and 
each  is  defined  by  the  diameter  of  the  optical  core.  The  first,  62.5  micrometers  core 
diameter,  is  supported  by  AT&T.  The  second,  supported  by  IBM,  has  a  core  diameter 
of  100  micrometers.  Because  of  cost,  the  62.5-micrometer  core  will  probably 
predominate.  The  100-micrometer  fiber  is  about  2^  times  more  expensive  than  the 
62.5.  FDDI  also  offers  such  benefits  as  virtually  unlimited  bandwidth,  very  low 
attenuation,  very  low  susceptibility  to  electromagnetic  interference  and  radio 
frequency  interference,  as  well  as  a  high  level  of  security. 

In  an  FDDI  ring,  there  are  class  A  stations  and  class  B  stations.  Class  B 
stations  are  the  cheaper  of  the  two  because  they  can  connect  to  either  the  primary  or 
the  secondary  ring  but  not  to  both.  Class  A  scations  are  connected  to  both  rings  and. 
although  more  expensive,  offer  the  benefit  of  continuous  operation  in  a  reconfigured 
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ring.  An  FDDI  network  can  be  configured  as  a  ring,  a  star,  or  a  branched  tree 
(similar  to  cable  television  installation). 

As  a  back-end  network,  FDDI  could  connect  computer  peripherals,  such  as  tape 
and  disk,  with  little  regard  for  the  distance  between  them.  FDDI  could  also  be  used 
to  connect  mainframe  computers  and  eliminate  the  need  for  the  FEPs  normally  used 
for  this  purpose.  It  is  compatible  with  lower  performance  standards  such  as  Ethernet 
and  token  ring,  and  its  unusually  high  performance  would  make  it  an  ideal  backbone 
for  LANs.  Graphics  workstations  and  CAD/CAM  applications,  which  can  easily  clog 
existing  networks,  will  benefit  greatly  from  the  greater  bandwidth  offered  by  FDDI. 

3.5.2  Fiber-Distributed  Data  Interface  Status 

Interest  in  FDDI  by  standards  organizations  and  vendors  is  quite  high. 
Because  few  vendors  have  any  products  or  proprietary  interests  to  protect,  FDDI  has 
become  one  of  the  fastest  evolving  standards  efforts  in  recent  times.  As  documenta¬ 
tion  for  the  FDDI  standards  nears  completion  (scheduled  for  mid- 1987),  vendors  and 
Government  agencies  alike  will  begin  prototype  efforts  for  this  emerging  network 
standard. 
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SECTION  4 


CONCLUSIONS  AND  RECOMMENDATIONS 


Telecommunications  requirements  unique  to  CALS,  including  data  exchange 
protocols  and  standards,  exist.  CALS  requires  transmission  of  specific  types  of  data 
at  a  high  bandwidth  to  accommodate  the  large  volume  of  data  associated  with 
engineering  drawings  and  technical  data.  However,  communications  media  and 
networks  to  support  CALS  will,  in  most  cases,  be  the  same  as  those  supporting  the 
DoD  community  as  a  whole.  Therefore,  any  recommendations  in  telecommuni¬ 
cations  for  CALS  must  consider  other  efforts  in  DoD  and  industry.  CALS  must 
accommodate  protocols  and  communications  media  that  support  DoD 
interoperability  requirements  and  the  interface  with  industry  systems.  In  addition, 
CALS  projects  must  work  with  non-CALS  projects.  Design  of  CALS  projects  requires 
an  understanding  of  the  issues  associated  with  integrating  the  various  systems  and 
databases  supporting  other  DoD  operations. 

Three  major  categories  of  issues  or  areas  of  concern  for  CALS  telecommuni¬ 
cations  were  identified  as  a  result  of  the  analysis  of  DoD  and  industry  communi 
cations  initiatives: 

•  Volume  requirements  for  CALS-data  transmission 

•  Efforts  to  specify  communications  protocol  standards  in  both  DoD  and 
industry 

•  Use  of  intelligent  gateways  (IGs). 

Table  4-1  summarizes  the  conclusions  and  recommendations  presented  in  the 
subsections  that  follow.  An  overall  approach  or  architecture  for  telecommunications 
for  CALS  is  presented  in  the  CALS  Telecommunications  Plan.  Specifics  for 
implementation  of  protocols  and  use  of  IGs,  as  well  as  security  issues,  are  addressed 
in  that  report. 

4.1  CALS  DATA  TRANSMISSION  VOLUME  REQUIREMENTS 

Many  of  the  CALS  efforts  include  automating  what  are  primarily  manual 
operations  today.  For  that  reason,  it  has  been  difficult  to  determine  the  long-haul 


TABLE  4-1 


ASSESSMENT  OF  DoD  AND  INDUSTRY  TELECOMMUNICATIONS 


Conclusion 


Recommendations 


DDN  in  Its  current  configuration  will  not  be 
able  to  accommodate  the  large  volumes  of 
information  associated  with  engineering 
drawings  and  technical  data 


The  Services  need  to  define  requirements  for  both  data  storage  and  data 
transmission  Capacity  modeling  techniques  using  data  from  ongoing 
projects  would  be  useful 

Prospective  CALS  projects  should  inform  the  DCA  of  their  projected  data 
volume  requirements,  as  they  become  available,  to  speed  the  mstal'a 
tion  of  higher  bandwidth  media 


Alternatives  for  reducing  the  cost  and  volume  of  CALS-related  traffit 
need  to  be  developed  and  eva'uated  these  include  storing  formatting 
information  at  user  workstations  trar'smitting  changes  to  documents 
rather  than  changed  documents,  and  maintaining  redundant  databases 


The  Services  should  more  thoroughly  investigate  the  advantages  of 
establishing  common  communication  links  with  other  DoD  and  industry 
organizations  and  avoid  establishing  proprietary  links  with  industry 


There  are  discrepancies  between  develop¬ 
ing  Services'  telecommunications  policy 
and  specific  implementations  to  support 
various  projects  The  reason  for  much  of 
this  IS  that  standards  for  transitioning  to 
OSI  have  not  yet  been  defined,  and  the 
Services  policy  is  still  under  development 


A  phased  migration  to  the  OSl  standards  is  needed  Users  must  require 
product  certification  and  carefully  evaluate  each  implementation  to 
ensure  full  compatibility  with  OSI 

Projects  that  have  not  yet  implemented  the  DoD  protocol  suite  should 
connect  to  DON  at  X  25  only  and  avoid  implementation  of  DoD 
Application  Layer  protocols  (e  g  ,  SMTP.  FTP,  etc  )  to  ease  transition  to 
OSI 


CALS  projects  should  adopt  the  GOSIP  specification  as  a  baseline  j 

protocol  suite  and  push  for  inclusion  of  VTP,  ES-to-lS,  iS-to-iS  m  the  i 

GOSIP  document,  which  will  make  the  GOSIP  document  functionally 
equivalent  to  the  present  DON  suite  , 


CSMA/CD  should  be  used  m  the  local  CALS  environment  to  link 
workstations  with  host  processors  CSMA/CD  running  on  10  Mbps  cable 
can  accommodate  both  document  and  graphics  interchange  cost 
effectively  individual  requirements  must  be  taken  into  consideration 


Transition  to  future  standards  developments  m  ISDN.  FDDI,  and  T-Carner  ■ 

Services  should  be  planned  carefully  for  adoption,  as  mature  standards  ‘ 

and  certified  specifications  become  available  [ 

The  Services  should  give  careful  >  onsideration  to  long-range  needs  f 

before  granting  waivers  for  situations  where  it  has  been  determined  ‘ 

that  interoperability  is  not  needed  ■ 


The  DoD  and  commercially  available  iGs  (as 
opposed  to  communications  gateways) 
have  been  designed  to  support  trans¬ 
mission  of  much  smaller  amounts  of 
information  than  is  generally  associated 
with  a  request  for  engineering  drawings  or 
technical  documents  In  addition,  the  IG 
architecture  for  CALS  involves  more 
complex  translation  capabilities  than  IGs  to 
support  simple  queries  and  retrievals  of 
rjata 


More  sophisticated  R8D  efforts  are  needed  frjr  the  development  nf  an 
IG  architecture  to  provide  a  user  ,i'  a  single  terminal  with  data  arress 
and  retrieval  capabilities  from  multiple  hererogeneous  sources 

The  IG  architecture  for  CAlS  must  address  translations  between 
different  graphics  and  technical  standards 

Standardization  of  proceiJures  and  practices  (engineering  modeling)  is 
needed  before  graphics  standards  are  useful  to  a  great  extent  iCis  can 
provide  solutions  in  the  interim 

To  avoid  some  of  the  limitations  asswi  ,ited  with  the  use  of  standards 
subset  laptions  can  he  defined  fi  n  use  hy  dif  fei  ent  a  p  pin  a  turns 


though  g.iteways,  wt h  their  inherent  i ne f  f  n  lerir  es  r  ejn esent  ,i n  in*,'  n> 
step  to  the  adoption  of  spec 'fa  ations  and  standards,  such  produris  w 
provide  the  best  means  fur  aciommodating  communa  ations  he'ween 
dissimilar  systems  for  many  years  to  <  ome 


communication  requirements  for  CALS-related  data.  As  part  of  the  effort  to 
automate  their  repositories  of  engineering  drawings  and  technical  data,  the  Services 
are  now  defining  not  only  data  requirements  for  local  databases  but  also  require 
ments  for  transmitting  these  data  over  communications  media.  The  added  task  of 
determining  what  data  are  actually  needed  in  digitized  form  adds  another  layer  of 
complexity  to  the  problem.  The  Services  must  take  account  of  the  likelihood  that 
once  the  capability  is  provided,  more  and  more  users  will  take  advantage  of  the 
services  offered,  far  exceeding  estimates  based  on  current  use. 

Figure  4-1  depicts  the  volume  of  data  associated  with  a  typical  weapon  system’s 
databases  as  determined  by  the  Air  Force  IDS  System  Program  Office.  Both  existing 
and  future  database  storage  requirements  are  presented.  Some  of  these  data  will  be 
available  on-line;  other  data  will  be  archived  and  used  infrequently  during  the  life  of 
the  weapon  system.  This  distinction  is  important  because  providing  on-line  access  is 
generally  a  great  deal  more  expensive  than  providing  access  to  archived  data. 

The  process  of  collecting  information  about  the  volume  of  data  is  itself  difficult 
and  time-consuming.  Capacity  modeling  techniques  will  be  useful  for  projecting 
CALS-related  data  transmission  requirements  and  are  discussed  in  more  detail  in 
the  CALS  Telecommunications  Plan. 

The  large  size  of  drawing  files  (8  megabytes  or  more)  and  the  current  maximum 
speed  of  the  DDN  (56  kbps)  make  the  exchange  of  large  volumes  of  image  informa¬ 
tion  over  the  DDN  inconvenient  or  inefficient.  The  DDN  in  its  current  configuration 
will  not  be  able  to  accommodate  the  large  volume  of  information  associated  with 
CALS.  Transmitting  1,500  aperture  cards  or  images  over  the  DDN  from  one  base  to 
another  would  take  approximately  30  hours.  This  assumes  a  20:1  compression  ratio 
and  includes  an  estimated  overhead  of  25  percent  imposed  by  the  various  protocols 
and  acknowledgments  used  within  DDN.  For  organizations  with  a  requirement  to 
transmit  similar  volumes  on  a  daily  basis,  overnight  mail  will  be  more  effective  for 
the  near  term. 

The  Services  plan  to  transmit  queries  to  the  databases  or  index  files  by  DDN 
and  send  large  volumes  of  data  by  overnight  mail.  Depending  on  the  volume  of 
information,  the  data  may  be  sent  on  optical  disk,  magnetic  tape,  aperture  card,  or 
hard  copy.  In  the  near  term,  this  is  the  most  cost  effective  way  to  transmit  data. 
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FIG.  4-1 .  TYPICAL  WEAPON  SYSTEM  DATABASES 


Standards  for  these  off-line  media  are  being  addressed  by  the  CALS  Specifications 
and  Standards  Group. 

The  DDN  may  also  be  used  to  transmit  a  small  number  of  priority  technical 
documents.  Drawings  should  be  transmitted  over  the  DDN  during  non-peak  hours 
only.  Leased  dedicated  high-speed  circuits  is  one  of  the  few  means  available  to 
achieve  the  long-distance,  on-line  transfer  of  drawings.  But  leasing  circuits  is  costly. 
As  the  technology  develops  and  becomes  standardized,  as  DC  A  makes  use  of  the  new 
technology  to  increase  the  speed  and  capacity  of  the  DDN  (estimated  to  be  in  5  years 
for  T1  capability),  and  as  long-distance  telecommunication  becomes  efficient  and 
cost-effective,  the  Services  will  increase  their  use  of  communications  media  for 
transmitting  these  data.  Actual  transfer  requirements  for  technical  documents  are 
still  being  determined  and  should  be  subjected  to  cost-benefit  analysis.  All 
prospective  CALS  projects  should  inform  the  DCA  of  their  projected  data  volume 
transmission  requirements,  as  they  become  available,  to  justify  the  installation  of 
higher  bandwidth  media  to  support  data  transfer  requirements. 

The  most  efficient  means  of  forms  processing,  from  a  communications 
viewpoint,  is  to  store  the  formatting  information  for  the  forms  at  the  user 
workstation  rather  than  transmit  the  formatting  data  with  user-entered  data.  In 
addition,  transmitting  changes  only  rather  than  transmitting  entire  documents 
would  essentially  eliminate  the  need  for  weekly  download  communications.  Data 
redundancy  would  be  a  requirement  until  the  communications  media  could  support 
transfers  of  the  required  volumes. 

Although  projections  vary  concerning  the  volume  of  CALS-related  data  that 
will  be  transmitted  from  one  Service  to  another,  all  the  Services  do  have  to  transmit 
such  data  electronically  to  one  another.  Moreover,  many  programs  within  the 
Services  have  indicated  that  they  have  no  intention,  in  the  near  term,  of  establishing 
communication  links  with  private  industry,  but  will  accept  data  in  the  form  of 
optical  disk,  magnetic  tape,  aperture  card,  or  hard  copy.  There  are  a  few  continuing 
efforts  in  DoD  to  establish  communication  links  with  various  commercial  organiza 
tions.  Most  of  these  projects  rely  on  proprietary  communications  media.  It  should  be 
expected  that,  over  the  long  term,  the  need  for  such  communication  links  will 
increase  as  their  value  becomes  moi  o  evident. 


4.2  EFFORTS  FOR  SPECIFYING  PROTOCOL  STANDARDS  IN  DoD  AND  INDUSTRY 


The  Office  of  Management  and  Budget  (0MB)  is  reviewing  considerations  for  a 
5-year  plan  to  meet  the  automation  and  telecommunications  needs  of  the  Federal 
Government  and  calls  for  a  Government-wide  policy  for  OSI.  NBS  Workshops  for 
Implementation  of  OSI  will  continue  to  promote  implementation  of  state-of-the-art 
network  standards  leading  to  development  of  off-the-shelf  commercial  products.  The 
0MB,  at  the  same  time,  clearly  recognizes  COS,  the  private-member  consortium 
dedicated  to  implementation  of  OSI  standards.  NBS  and  COS  do  not  represent 
conflicting  interests;  they  are  working  together  toward  implementation  of  OSI 
standards.  NBS  will  continue  to  pursue  Federal  Information  Processing  Standards 
(FEPS)  that  will  include  protocol  specifications,  conformance  tests,  and  user  guidance 
for  optimal  usage  by  Federal  agencies.  The  goal  is  to  issue  FIPS  for  all  seven 
protocol  layers  within  the  next  2  —  5  years. 

Both  the  Navy  and  the  Air  Force  are  developing  planning  strategies  for 
transitioning  to  the  ISO  standards  as  they  become  available.  All  the  Services  have 
indicated  their  intention  to  migrate  to  ISDN  in  the  future.  Navy  guidance 
encourages  use  of  international  standards  for  new  developments  unless  there  is  a 
compelling  requirement  for  interoperability  with  an  existing  system  using  DoD 
protocols  before  1988.  This  does  not  preclude  use  of  other  protocols  in  situations 
where  interoperability  is  not  needed.  However,  careful  consideration  should  be 
given  to  long-range  needs.  The  Navy  has  stated  that  only  5  percent  of  Navy 
facilities  —  made  up  primarily  of  the  research  community  —  have  implemented  such 
Application  Layer  protocols  as  FTP  and  SMTP.  The  bulk  of  Navy  facilities 
(approximately  80  percent)  are  using  proprietary  protocols  (e.g.,  SNA  and 
DECNET).  Therefore,  unless  there  is  an  urgent  need  to  interoperate  with  another 
facility  and  unless  packages  can  be  bought  off  the  shelf  (it  can  take  at  least  H  staff- 
years  to  develop  these  protocols  for  a  specific  hardware/software  suite),  not  only  the 
Navy  but  all  the  Services  should  begin  to  gear  up  for  OSI  standards  rather  than  the 
DoD  Application  Layer  protocols. 

Discrepancies  in  protocols  specified  by  various  Air  Force  programs  are  under 
review  by  HQ  Air  Force.  The  ULANA  II  Conceptual  Protocol  Suite  Architecture  is 
very  similar  to  TOP  and  is  a  superset  of  GOSIP.  'Fhe  CDS  project  specifies  I'LA.N'A  I 
protocols;  EDCARS  specifies  the  HDH  Interface  to  DDN,  which  is  very  old  and 
should  be  replaced  with  X.25/LAPB.  'Fhe  Air  Force  is  looking  into  protocols  being 


specified  by  these  and  other  programs  to  ensure  conformity  with  ULANA  II.  In 
addition,  proprietary  protocols  are  installed  with  each  implementation  of  a  fiber¬ 
optic  network  in  the  Air  Force.  Since  fiber-optic  standards  are  not  yet  available,  Air 
Force  programs  should  wait  for  FDDI  and  be  consistent  with  ULANA  II 
specifications. 


Service  plans  are  still  in  draft  form  and  are  waiting  for  DCA  guidance  on  which 
protocols  or  subsets  of  protocols  should  be  implemented.  The  Services  keep  up  with 
the  development  of  protocol  standards  in  DoD  through  the  Protocol  Standards 
Steering  Group,  chaired  by  the  Defense  Communications  Engineering  Center 
(DCEC).  The  protocols  outlined  in  the  individual  Services’  plans  should  be  expected 
to  change  as  standards  agreements  are  reached.  To  ensure  conformity  within  DoD, 
development  of  these  plans  should  be  reviewed  as  they  become  available. 


The  Services  are  looking  to  the  OSI/DoD  gateway  under  development  at  NBS  to 
provide  the  necessary  interfaces  between  the  DoD  protocols  as  they  exist  today  and 
the  ISO  standards  to  be  adopted  by  DoD  in  the  future.  A  draft  of  the  transition  plan 
should  be  available  by  mid- 1987  as  part  of  this  joint  NBS/DCA/OSD  gateway 
prototype  project.  An  experimental  phase  is  expected  to  last  for  approximately 
2  years.  During  this  period,  areas  in  which  GOSIP  falls  short  of  DDN  capabilities 
will  be  addressed.  NBS  is  concerned  primarily  with  development  of  an  application 
gateway  to  support  translations  from  FTP  to  FT  AM,  and  from  SMTP  to  X.400.  This 
gateway  should  be  available  by  early  1988.  DCA  has  contracted  with  the  MITRE 
Corporation  for  development  of  the  network  gateway  to  support  the  lower- layer 
translation  requirements.  Several  OSI  conformance  tests  are  available  or  planned. 
The  NBS  is  also  developing  protocol  testing  facilities.  This  will  greatly  aid  and 
expedite  implementation  of  the  OSI  protocol  layers. 


Such  gateways  are  the  best  means  of  accommodating  communications  between 
existing  implementations  of  the  DoD  protocols  suite  and  the  OSI  suite.  However, 
users  should  be  aware  that  gateways  impose  additional  overhead  on  the  overall 
communications  process.  Therefore,  projects  that  have  not  yet  implemented  the  DoD 
protocol  suite  should  connect  to  the  DDN  at  .K.25  only  and  adopt  the  GOSIP 
specification  as  a  baseline  protocol  suite.  Although  gateways,  with  their  inherent 
inefficiencies,  are  an  interim  step  to  the  adoption  of  specifications  and  standards. 


such  products  will  provide  advantages  and  benefits  for  communication  among 
dissimilar  systems  for  years  to  come. 

In  the  private  sector,  COS  and  the  MAP/TOP  Users  Group  have  agreed  to  co¬ 
sponsor  an  exhibition  devoted  primarily  to  the  display  of  MAP/TOP  networks. 
Planned  for  the  summer  of  1988  in  Baltimore,  Md.,  the  exhibition  will  demonstrate 
the  MAP/TOP  and  COS  computer  communications  specifications  operating  in  a  real- 
world  environment.  More  than  50  computer  and  communications  vendors  are 
expected  to  participate.  This  supports  the  fact  that  OSI  will  eventually  overtake 
DDN  and  that  vendors  are  committed  to  the  OSI  protocols. 

COS  will  be  using  the  exhibition  as  an  opportunity  to  launch  its  testing  and 
certification  processes.  It  is  sponsoring  the  development  of  tests  for  FTAM  and 
MHS  X.400.  The  MAP/TOP  Users  Group  is  sponsoring  the  development  of  tests  for 
manufacturing  message  services,  network  management,  and  network  directory 
services  protocols.  Unlike  the  MAP  demonstration  at  the  Autofact  ’85  show,  which 
was  a  prototype  version  of  future  products,  the  users  group  wanted  the  MAP.TOP 
Release  3.0  demonstration  to  show  product-level  components.  The  user  organization 
decided  that  a  series  of  tests  would  be  needed  to  achieve  this.  All  suppliers, 
including  hardware  and  networking  vendors,  will  be  required  to  pass  the  confor¬ 
mance  tests  to  make  sure  that  their  products  adhere  to  the  MAP/TOP  Release  3.0 
specifications.  MAP/TOP  Release  3.0  was  originally  scheduled  to  debut  this 
November.  The  delay  of  the  exhibition  has  nothing  to  do  with  the  development  of  the 
MAP/TOP  Release  3.0  specifications,  which  should  still  be  ready  by  the  end  of  1987. 

The  complex  and  expensive  task  of  establishing  networking  standards  for  the 
factory  floor  and  office  environment  has  prompted  the  MAP/TOP  Users  Group  to 
seek  both  technical  and  financial  assistance  from  COS.  COS  will  take  development 
and  financial  responsibility  for  approximately  40  percent  of  the  testing  effort,  which 
will  have  a  total  estimated  cost  of  between  $15  million  and  $20  million. 

A  phased  migration  plan  to  the  OSI  standards  is  needed  in  DoD  because  several 
of  the  protocols  required  by  CALS  projects  are  not  yet  available.  This  is  the  approach 
taken  in  the  CALS  Telecommunications  Plan.  Several  vendors  have  implernenta 
tions  of  the  OSI  protocols,  and  many  more  have  said  they  will  provide  products  in  the 
near  future.  Users  must  require  product  certification  and  carefully  evaluate  each 
implementation  to  ensure  full  compatibility. 
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Specific  recommendations  for  DoD  CALS  telecommunications  include: 


•  CALS  projects  that  have  not  yet  implemented  the  DoD  protocol  suite  should 
connect  to  DDN  at  the  X.25  layer  only  and  avoid  implementation  of  the 
upper-layer  protocols  (e.g.,  FTP,  SMTP,  etc.)  to  facilitate  transition  to  OSI. 

•  The  CALS  projects  should  adopt  the  GOSIP  specification  as  a  baseline 
protocol  suite.  The  CALS  projects  should  push  for  inclusion  of  the  VTP 
basic  class,  the  ES-to-IS  Routing  Exchange  Protocol,  and  the  Intermediate 
System  to  Intermediate  System  (IS-to-IS)  Routing  Exchange  Protocol  in  the 
GOSIP  specification  as  soon  as  possible.  Inclusion  of  these  protocols  will 
make  the  GOSIP  specification  functionally  equivalent  to  the  present  DDN 
suite.  These  protocols  should  be  available  within  the  year.  In  the 
meantime,  the  CALS  projects  will  be  able  to  accomplish  file  terminal  access 
until  VTP  and  the  changes  that  must  be  made  to  the  Mini-TAC  are 
accomplished.  The  plan  to  accommodate  remote-terminal  access  is  based  on 
having  the  Mini-TACs  upgraded  to  support  both  protocol  suites.  This  is  not 
part  of  the  present  contract  and  would  most  likely  become  an  extension  to  it. 
No  acquisition  approach  has  been  determined  to  date.  In  the  absence  of  the 
ES-to-IS,  only  static  routing  will  be  available.  The  TOP  User  Group  has 
deemed  both  ES-to-IS  and  VTP  complete  enough  for  inclusion  in  their 
Version  3.0  architecture.  The  IS-to-IS  protocol  will  probably  not  be 
available  before  April  1988. 

•  The  NBS  application  gateway  being  developed  will  provide  FTP  to  FTAM 
and  SMTP  to  X.400  protocol  translations  by  the  beginning  of  1988.  Use  of 
the  NBS  gateway,  once  delivered,  should  be  minimized.  Translation 
gateways  of  this  type  are  inefficient  because  of  the  overhead  imposed  by 
translation.  For  the  long  term,  it  is  better  for  the  Services  to  plan  to 
implement  the  OSI  protocols  rather  than  rely  on  gateways. 

•  The  TOP  protocol  stack.  Version  3.0,  already  specifies  the  above-listed 
protocols,  as  well  as  others  that  are  applicable  to  the  CALS  projects.  This 
protocol  stack,  which  is  being  promoted  by  the  private  sector,  should  provide 
direction  for  a  complete  CALS  telecommunications  plan.  The  TOP  data 
exchange  protocols  specified  are  also  required  by  the  CALS  projects  and 
should  be  adopted. 

•  The  MAC  protocol  known  as  the  CSMAjCD  protocol  should  be  used  in  the 
local  environment  to  link  CALS  workstations  with  host  processors. 
CSMA/CD  running  on  10  Mbps  cable  can  accommodate  both  document  and 
graphics  interchange  in  a  cost-effective  manner.  The  physical  medium 
selected  is  dependent  on  the  specific  project  requirements.  Broadband  coax 
cable  may  be  appropriate  where  there  is  a  requirement  to  support  a  mix  of 
communications  over  longer  distances  or  additional  bandwidth  is  required 
to  support  the  data  volume. 
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•  The  MIL-STD-1840  specification  now  states  that  the  DDN  protocols  TCP/IP 
will  be  used  to  ease  transmission.  The  GOSIP-specified  ISO/OSI  protocols 
should  also  be  included  as  an  alternative  to  DDN  for  providing  the 
communications  protocols  below  the  data  exchange  protocols  specified  in 
MIL-STD-1840. 

•  ISDN  will  be  a  solution  to  CALS  data  transmission  workloads  in  the  1990s. 
There  is  still  considerable  work  that  must  be  completed  before  it  is 
standardized  and  the  required  broadband  services  are  made  available. 

•  FDDI  should  be  made  available  in  1988  —  89.  This  specification  should  be 
used  for  optical  systems  implemented  to  support  CALS  projects. 

•  T-Carrier  services  are  available  but  not  yet  standardized.  Prospective  users 
should  be  made  aware  that  vendors  are  using  proprietary  schemes  that  will 
make  heterogeneous  communications  difficult  and  probably  dictate  the  use 
of  only  one  vendor’s  equipment.  A  cost-benefit  analysis  is  required  before 
this  can  become  a  viable  solution. 

4.3  USE  OF  INTELLIGENT  GATEWAYS 


The  previous  subsection  addressed  the  importance  of  communications  gate¬ 
ways,  such  as  the  OSI/DoD  gateway  under  development  at  NBS.  for  accommodating 
communications  at  all  seven  layers  of  the  OSI  Model.  These  products  address  the 
overall  basic  communications  functions  for  communicating  between  dissimilar 
systems.  IGs,  on  the  other  hand,  are  more  concerned  with  data  formats,  semantics, 
and  differences  in  application  software  and  DBMSs  among  different  systems. 

An  IG  is  a  hardware'software  configuration  that  enables  a  user  at  a  single 
terminal  to  access  and  retrieve  information  fro.m  dissimilar  systems  readily.  .-Xn  IG 
may  or  may  not  include  communications  gateway  functions  along  with  the  higher 
level  (Layers  6  and  7)  application  programs  written  to  support  the  required  user 
interfaces.  For  purposes  of  this  report,  the  DoD  IG  efforts  presented  in  Section  2  can 
be  described  as  one  of  two  types.  The  first,  refi'rred  to  here  ,i  Basic  Gateway 
Systems,  provides  a  comparatively  inexpensive  means  of  providi ng  a  user  at  a  single 
terminal  with  data  access  and  retrieval  capabilities  from  multifile  iieterogeneous 
sources.  The  Basic  Gateway  Systems  provide  the  user  w  th  transfiarent  log-iin  to  the 
target  host.  In  some  cases  the  menu  driven  systems  will  also  retrievt*  the 
information  from  the  t.arg*  t  ho^t  .uid  reformat  the  data  fu  the  ii>er.  or  the  user  can 
make  use  of  a  pass-through  capahility  to  the  target  host.  Howav.  r.  onee  logged  on  in 
this  manner,  the  user  must  know  the  comn'.and  language  of  the  t  emote  system. 
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The  basic  gateway  approach  is  the  simplest  to  implement.  The  system  itself  is 
seen  as  a  terminal  by  the  target  computer  system  and,  in  general,  does  not  know  and 
has  no  need  to  know  what  hardware,  operating  system,  DBMS,  or  other  software  is 
supported  at  the  remote  location.  The  system  only  needs  to  know  that  data  is  to  be 
sent  in  asynchronous  ASCII  format.  The  following  capabilities  are  provided  by  some 
of  the  commercial  gateway  applications  available  today: 

•  Transparent  dial-up  and  log-on 

•  Menu-driven  system  for  formulating  user  queries 

•  Software  to  determine  which  database(s)  should  be  accessed 

•  Data  retrieval  and  postprocessing. 

Any  and  all  conversions  (to  ASCII  and  to  accommodate  record  layout  and  data 
element  format  requirements)  are  handled  by  the  gateway.  The  target  computer 
system  simply  receives  and  processes  the  data  sent  by  the  gateway,  without  knowing 
where  the  data  have  originated.  The  basic  gateway  systems  offer  a  limited  search 
strategy  that  is  more  than  adequate  for  the  types  of  data  retrieval  needed  to  support 
many  CALS  operations.  Examples  of  Basic  Gateway  Systems  in  DoD  include  the  Air 
Force’s  CDS  and  LOGDIS,  and  the  Navy’s  TLRN.  The  Navy’s  SPLICE  is  also  a  form 
of  IG  which,  in  addition,  provides  communication  protocol  translations  not  supported 
in  the  other  gateway  projects. 

The  second  type  of  IG  is  the  heterogeneous  distributed  database  management 
system  (DDBMS).  These  systems  offer  the  full  range  of  capabilities  needed  by 
programmers  and  experienced  users.  The  heterogeneous  DDBMSs  are  also  highly 
experimental  at  this  time  and  are  much  more  expensive  to  implement  than  the  Basic 
Gateway  Systems.  These  systems  have  been  designed  primarily  to  provide  the  more 
experienced  user  with  a  global  data  definition  language  for  retrieving  data  from 
heterogeneous  databases  rather  than  using  menu-driven  prompts.  These  systems 
interface  directly  with  the  DBMS  on  the  target  host.  They  do  not  require  any 
changes  to  the  preexisting  databases,  their  DBMSs,  or  their  application  programs. 
They  provide  the  user  with  a  more  flexible  and  far-reaching  data  retrieval 
capability.  Examples  of  heterogeneous  DDBMS  projects  include  the  MULTIBASE 
efforts  underway  in  the  Army  and  the  Air  Force’s  IDS  project. 

The  basic  gateway  approach  can  support  a  limited  number  of  types  of  queries 
where:  (1)  the  request  is  a  standard,  predefined  query,  (2)  only  one  to  a  few  programs 


(batch  or  interactive)  have  to  be  accessed  at  the  target  system,  and  (3)  only  some  data 
elements  must  be  accessed  in  the  databases  or  files  on  the  target  host.  In  such  cases, 
the  users’  questions  and  the  responses  to  them  are  known  in  advance;  in  such 
situations,  the  basic  gateway  approach  could  prove  to  be  the  most  cost-effective  one. 
The  target  host  facility  would  have  more  control  over  user  access  to  its  data. 

For  the  long  term,  an  IG  should  enable  the  user  to  formulate  a  wide  range  of 
queries  accessing  any  data  element  in  the  target  database(s).  In  this  case,  it  is  not 
possible  to  predefine  the  questions  to  be  asked  or  the  data  elements  to  be  retrieved. 
An  intermediary  or  common  query  language,  such  as  that  developed  in  the  heteroge¬ 
neous  DDBMS  projects,  is  needed  to  accommodate  translation  to  various  DBMSs  and 
files.  Security  is  a  major  issue  to  be  addressed  in  such  projects. 

Existing  IG  projects  for  the  most  part  handle  queries  that  result  in  the 
transmission  of  much  smaller  amounts  of  information  than  is  generally  associated 
with  a  request  for  an  engineering  drawing  or  technical  data.  The  IG  for  CALS  must 
address  two  main  issues:  how  to  accommodate  the  transmission  of  large  volumes  of 
information  and  how  to  handle  translation  between  different  graphics  and  technical 
data  standards.  The  problems  of  conversion  and  translation  of  text  are  more  or  less 
straightforward.  However,  as  we  have  seen,  in  graphics  there  are  a  number  of 
problems  that  make  the  task  difficult  and  economically  infeasible  within  available 
technology.  Even  if  agreement  is  reached  for  use  of  a  particular  subset  of  a  standard, 
there  must  also  be  agreement  on  the  practices  and  procedures  (engineering  models) 
used  to  work  with  or  display  those  data.  The  IG  may  be  able  to  accommodate  these  to 
some  extent.  A  number  of  companies  are  developing  pre-  and  post-translators 
between  their  CAD  graphics  package  and  IGES.  For  example.  Computer  Vision  and 
CAD  AM  have  both  developed  such  translators.  It  will  be  some  time  before  these 
products  will  be  completed,  but  they  will  never  be  able  to  provide  the  100  percent 
translation  that  is  needed  for  effective  use  of  CAD/CAM  data  between  two  or  more 
proprietary  CAD/CAM  systems. 

Other  system  differences  that  must  be  addressed  include  the  fact  that  in  some 
cases  there  simply  is  no  representation  in  one  system  for  elements  represented  in  the 
other.  In  order  not  to  be  too  limiting,  a  number  of  options,  corresponding  to  different 
applications,  could  be  made  available  as  subsets  to  the  standards.  Although  there 
may  be  resulting  limitations  within  any  one  particular  application,  the  risk  could  be 


lowered  with  options  that  would  depend  on  the  application,  thereby  increasing  the 
scope  of  the  standard. 

The  Services  are  adopting  SQL  as  the  standard  database  language.  SQL  is 
appropriate  for  simple  query  requirements,  but  the  SQL  model  is  at  too  low  a  level  to 
meet  DoD  requirements  for  engineering  systems.  For  example,  the  Army 
MULTIBASE  effort  recently  completed  a  conversion  to  Ada,  complying  with  the 
mandate  to  use  Ada  with  the  Common  Ada  Programming  Support  Environment 
(APSE)  Interface  Set  (CAIS)  as  the  user  interface  language.  SQL  cannot  interface 
effectively  with  the  more  complex  functions  supported  by  CAIS  and,  therefore, 
cannot  be  used  on  the  database  side  of  CAIS.  The  CALS  Telecommunications  Plan 
will  address  the  major  issues,  difficulties,  and  complexities  associated  with  the  use  of 
IGs  to  integrate  heterogeneous  systems  and  databases. 

4.4  CALS  TELECOMMUNICATIONS  PLAN 

The  CALS  Telecommunications  Plan  was  available  for  distribution  in  draft 
form  in  June  1987.  The  plan  presents  an  overall  approach  or  architecture  for 
telecommunications  for  CALS  and  provides  a  timetable  for  implementation  of 
specific  communications  functions  and  protocols.  The  architecture  provides  a 
comprehensive  list  of  data  communications  protocols,  data  exchange  protocols,  and 
transmission  media  to  ease  local  and  long-haul  communications  within  DoD  and 
between  DoD  and  industry. 

The  approach  for  CALS  telecommunications  is  divided  into  three  phases. 
Implementation  for  the  near  term  (1987  —  88)  concentrates  on  commercially 
available,  off-the-shelf  technology.  The  mid-term  phase  (1989—91)  concentrates  on 
technology  that  is  expected  to  become  stabilized  or  standardized  in  that  timeframe. 
The  long  term  (1992  and  beyond)  completes  the  communications  architecture 
required  to  support  the  CALS  environment  and  its  specific  needs. 

An  IG  architecture  for  CALS  is  developed  in  the  plan  concentrating  on  Layers  6 
and  7,  addressing  the  distinction  between  simple  "interfacing”  and  "integration”  or 
understanding.  A  number  of  issues  associated  with  achieving  the  integration  goal 
include: 

•  Integrating  across  different  data  models 

•  Integrating  across  different  software  systems 
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•  Integrating  across  different  business  environments 

•  Providing  an  effective  user  interface 

•  Ensuring  data  quality 

•  Addressing  performance  and  security. 

An  overall  approach  for  realizing  the  IG  architecture  in  these  timeframes  is 
presented. 

Each  phase  will  build  on  the  preceding  phase  in  capabilities  provided  and 
contain  recommendations  on  technology  refreshment.  The  final  plan  will  serve  as  a 
statement  of  direction  to  vendors  and  industry  contractors  of  the  standards  that  will 
be  used  to  provide  interoperability. 
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GLOSSARY 


A&L  =  Acquisition  and  Logistics 

AAR  =  Automatic  Alternate  Routine 

ACC  =  Army  Communications  Command 

ACF  =  Advanced  Communications  Function 

ACSE  =  Associative  Control  Service  Elements 

AFB  =  Air  Force  Base 

AFLC  =  Air  Force  Logistics  Command 

AGMC  =  Aerospace  Guidance  and  Metrology  Center 

AAR  =  Automatic  Alternate  Routine 

ALC  =  Air  Logistics  Center 

ALMSA  =  Automated  Logistics  Management  Systems  Activity 

AMC  =  Army  Materiel  Command 

AMCCOM  =  Armament,  Munitions,  and  Chemical  Command 

ANSI  =  American  National  Standards  Institute 

APADE  =  Automation  of  Procurement  and  Accounting  Data  Entry 

APSE  =  Ada  Programming  Support  Environment 

ARPANET  =  Advanced  Research  Projects  Agency  Network 

ASC  =  Accredited  Standards  Committee 

ASCII  =  American  Standard  Code  for  Information  Interchange 

ASD  =  Aeronautical  Systems  Division 

ASN  I  =  Abstract  Syntax  Notation 

AT&T  =  American  Telephone  and  Telegraph 

Automated  Technical  Order  System 


ATOS 


AUTODIN 


B 

BAS 

BBN 

BCS 

bps 

BSC 

BSS 

CAD 

CAE 

CAIS 

CALS 

CAM 

CASC 

CASE 

CCA 

CCITT 

CCR 

CDC 

CDS 

CECOM 

COM 

CLNS 


=  Automatic  Digital  Network 
=  Bearer 

=  Basic  Activity  Subset 

=  Bolt,  Beranek  and  Newman 

=  Basic  Combined  Subset 
=  bits  per  second 

=  bisynchronous 
=  Basic  Synchronized  Subset 
=  computer-aided  design 

=  computer-aided  engineering 

=  Common  APSE  Interface  Set 

=  Computer  Aided  Logistics  Support 
=  computer-aided  manufacturing 
=  Cataloging  and  Standardization  Center 
=  Common  Application  Service  Elements 
=  Computer  Corporation  of  America 

=  Consultative  Committee  on  International  Telephony  and 
Telegraphy 

=  commitment,  concurrency,  and  recovery 
=  Control  Data  Corporation 

=  Central  Datacomm  System 

=  Communications  —  Electronics  Command 

=  Computer  Graphics  Metafile 

=  Connectionless  Network  Service 
=  Common  Management  Information  Protocol 
=  Continental  United  States 

=  Corporation  for  Open  Systems 


CMIP 

CONUS 

COS 


COSIS 

CSMA/CD 

D 


DA 

DAAS 

DAC 

DACOM 

DACS 

dB 

DBMS 

DCA 

DCE 

DCEC 

DCS 

DCTN 

DDBMS 

DDN 

DDS 

DECNET 

DESCOM 

DIDS 

DISNET 

DLA 

DLANET 

DoD 

DOS 

DSO 


=  Care  of  Supplies  in  Storage 

=  Carrier  Sense  Multiple  Access  with  Collision  Detection 
=  Delta 

=  Department  of  the  Army 

=  Defense  Automatic  Addressing  System 

=  Data  Communications 

=  D.  Appleton  Company 

=  Digital  Access  and  Cross-Connect  Service 

=  decibel(s) 

=  database  management  system 

=  Defense  Communications  Agency 

=  Data  Communication  Equipment 

=  Defense  Communications  Engineering  Center 

=  Defense  Communications  System 

=  Defense  Commercial  Telecommunications  Network 

=  distributed  database  management  system 

=  Defense  Data  Network 

=  Dataphone  Digital  Service 

=  Digital  Equipment  Corporation  Network 

=  Depot  Systems  Command 

=  Defense  Integrated  Data  System 

=  Defense  Integrated  Secure  Network 

=  Defense  Logistics  Agency 

=  DLA  Network 

=  Department  of  Defense 

=  Disk  Operating  System 

=  Digital  Signal  Level  0 
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DSP 

= 

Display  Services  Protocol 

DSREDS 

= 

Digital  Storage  and  Retrieval  Engineering  Data  System 

DTE 

= 

Data  Terminal  Equipment 

ECSA 

= 

Exchange  Carriers  Standard  Association 

EDGARS 

= 

Engineering  Data  Computer  Assisted  Retrieval  System 

EDI 

= 

Electronic  Data  Interface 

EDMICS 

zz 

Engineering  Drawing  Management  Information  and  Control 
System 

EGP 

= 

Exterior  Gateway  Protocol 

EIA 

= 

Electronic  Industries  Association 

EIR 

zz 

Equipment  Improvement  Recommendation 

ES-to-IS 

= 

End  System  to  Intermediate  System 

5ESS 

= 

No.  5  Electronic  Switching  System 

FDC 

= 

Federal  Data  Corporation 

FDDI 

z= 

Fiber  Distribution  Data  Interface 

FDM 

zz 

frequency  division  multiplexing 

FEP 

= 

front-end  processor 

FIPS 

= 

Federal  Information  Processing  Standards 

FORSCOM 

= 

Forces  Command 

FRID 

zz 

Functional  Requirements  and  Interface  Document 

FT  AM 

= 

File  Transfer,  Access,  and  Management 

FTP 

= 

File  Transfer  Protocol 

GDM 

zz 

global  data  manager 

GDT 

= 

graphic  display  terminal 

GHz 

zz 

gigahertz 

GKS 

zz 

Graphics  Kernel  System 

GOSIP 

= 

Government  Open  Systems  Interconnection  Profile 
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H 

— 

Higher  Speed 

HDH 

= 

HDLC  Distant  Host 

HDLC 

— 

High-Level  Data  Link  Control 

HGP 

— 

Host-to-Gateway  Protocol 

HQ 

— 

headquarters 

IBM 

— 

International  Business  Machines 

ICMP 

= 

Internet  Control  Message  Protocol 

ICP 

= 

inventory  control  point 

IDS 

= 

Integrated  Design  Support 

IEEE 

= 

Institute  of  Electrical  and  Electronic  Engineers 

IG 

= 

intelligent  gateway 

IGES 

=z 

Initial  Graphics  Exchange  Standard 

IGP 

= 

Intelligent  Gateway  Processor 

ILS 

= 

integrated  logistics  support 

IMP 

=: 

Interface  Message  Processor 

IP 

= 

Internet  Protocol 

IPS 

rr 

Information  Processing  Systems 

IS-to-IS 

Intermediate  System  to  Intermediate  System 

ISC 

= 

Information  Systems  Command 

ISDN 

= 

Integrated  Services  Digital  Network 

ISG 

intersite  gateway 

ISO 

= 

International  Standards  Organization 

ISTC 

= 

Information  Systems  and  Technology  Center 

m 

Industrial  Technology  Institute 

JTM 

= 

job  transfer  and  manipulation 

kbps 

rz 

kilobits  per  second 

LAN 

— 

local  area  network 

(ili)ss  5 


LAPB 

LATA 

LDI 

LLC 

LLNL 

LMI 

LOG 

LOGDIS 

LSA 

LSAR 

MAC 

MAP 

Mbps 

MHS 

MHz 

MICOM 

MILNET 

MLS 

MMS 

MS  DOS 

NARDAC 

NARF 

NAVAIR 

NAVDAC 

NAVSEA 

NAVSUP 


Link  Access  Protocol  Balanced 
local  access  and  transport  area 
local  database  interface 
Logical  Link  Control 

Lawrence  Livermore  National  Laboratories 
Logistics  Management  Institute 
Logistics 

Logistics  Data  Information  System 
logistics  support  analysis 
logistics  support  analysis  record 
Media  Access  Control 
Manufacturing  Automation  Protocol 
megabits  per  second 
Message  Handling  System 
megahertz 
Missile  Command 
Military  Network 
multilevel  security 
Manufacturing  Message  System 
Microsoft  Disk  Operating  System 
Navy  Regional  Data  Center 
Naval  air  rework  facility 
Naval  Air  Command 
Navy  Data  Automation  Command 
Naval  Sea  Systems  Command 
Naval  Supply  Systems  Command 
Navy  Telecommunications  Command 


NAVTELCOM 


NBS 

NCP 

NESEC 

NETC 

NMP 

NRRC 

OASD 

ODA 

ODIF 

0MB 

OSD 

OSI 

OSINET 

PBX 

PC 

PCM 

PDES 

PLP 

PMO 

PSN 

R&D 

R&M 

RBOC 

RF 

RFP 

RIM 


=  National  Bureau  of  Standards 

=  Network  Control  Program 

=  Naval  Electronics  Systems  Engineering  Center 
=  Network  Evaluation  and  Test  Center 
=  National  Maintenance  Point 
=  Naval  reserve  readiness  command 
=  Office  of  the  Assistant  Secretary  of  Defense 
=  Office  Document  Architecture 

=  Office  Document  Interchange  Format 

=  Office  of  Management  and  Budget 
=  Office  of  the  Secretary  of  Defense 
=  Open  Systems  Interconnection 
=  OSI  Network 

=  Private  Branch  Exchange 
=  personal  computer 
=  Pulse  Code  Modulation 
=  Product  Definition  Exchange  Specification 
=  Packet  Level  Protocol 
=  Program  Management  Office 
=  packet-switching  node 
=  research  and  development 
=  reliability  and  maintainability 
=  regional  Bell  operating  company 
=  radio  frequency 
=  request  for  proposals 
=  Relational  Information  Management 

=  Resource  Management  System 


RMS 


SAC 

SAMMS 


Strategic  Air  Command 

Standard  Automated  Material  Management  System 

SASE  =  Specific  Application  Service  Elements 

SCINET  =  Sensitive  Compartmented  Information  Network 

SEW  =  scientific  engineering  workstation 

SGML  =  Standard  Generalized  Markup  Language 

SMTP  =  Simple  Mail  Transfer  Protocol 

SNA  =  System  Network  Architecture 

SNAP  =  Standard  Network  Access  Protocol 

SNDCP  =  Subnetwork  Dependent  Convergence  Protocol 

SPAWAR  =  Space  and  Naval  Warfare  Systems  Command 

SPLICE  =  Stock  Point  Logistics  Integrated  Communications 

Environment 

SPLICENET  =  SPLICE  Network 

SPO  =  System  Program  Office 

SQL  =  Structured  Query  Language 

SYSCOM  =  Systems  Command 

TAC  =  Terminal  Access  Controller 

TCP  =  Transmission  Control  Protocol 

TDCMS  =  Tech  Data  Configuration  Management  System 

TDM  =  time  division  multiplexing 

TLRN  =  Technical  Logistics  Reference  Network 

TO  =  Technical  Order 

TOP  =  Technical  and  Office  Protocol 

TP  =  Transport  Protocol 

TP-4  =  Transport  Protocol  Class  4 

UADPS-SP  =  Uniform  Automated  Data  Processing  System  —  Stock  Point 


UDI 


unrestricted  digital  information 
UDP  =  User  Datagram  Protocol 

ULANA  =  Unified  Local  Area  Network  Architecture 

USAISC  =  U.S.  Army  Information  Systems  Command 

VDT  =  video  display  terminal 

VTAM  =  Virtual  Telecommunications  Access  Method 

VTP  =  Virtual  Terminal  Protocol 

WAN  =  wide-area  network 

WPAFB  =  Wright-Patterson  Air  Force  Base 

X.400  =  CCITT  Message  Handling  Protocol 


APPENDIX  A 

NAVY  COMMUNICATIONS  PROTOCOL  STANDARDS 


NAVY  COMMUNICATIONS  PROTOCOL  STANDARDS 

APPLICATION  LEVEL 

The  Navy  is  considering  use  of  the  following  protocols  for  the  specified  actions: 

File  Transfer 

Use:  File  Transfer,  Access,  and  Management  (FT AM) 

Spec:  Information  Processing  Systems  —  Open  Systems 
Interconnection  (IPS-OSI)  —  FTAM  {in  four  parts) 

Part  1  —  General  Description  ISO  DIS  8571/1 
Part  2  —  The  Virtual  Filestore  ISO  DIS  8571/2 
Parts  —  Service  Definition  ISO  DIS  8571/3 
Part  4  —  Protocol  Specification  ISO  DIS  8571/4 

Electronic  Mail 

Use:  Electronic  Mail  Consultative  Committee  on  International  Telephony 
and  Telegraphy  (CCITT)  X.400  Recommendations 

Spec:  Message  Handling  Systems  Series 

X.400  —  Systems  Model  —  Service  Elements 

X.401  —  Basic  Service  Elements  and  Optional  User  Facilities 

X.408  —  Encode  Information  Type  Conversion  Rules 

X.409  —  Presentation  Transfer  Syntax  and  Notation 

X.410  —  Remote  Operations  and  Reliable  Transfer  Server 

X.411  —  Message  Transfer  Layer 

X.420  —  Interpersonal  Messaging  User  Agent  Layer 

Application  Access  Control 

Use:  Common  Application  Service  Elements  (CASE) 

Spec:  Information  Processing  —  OSI 
Definition  of  CASE 

Part  1  —  Introduction  ISO  DP  8649/1 
Part  2  —  Basic  Kernel  ISO  DP  8649/2 

Part  3  —  Commitment,  Concurrence,  and  Recovery  ISO  DP  8649/3 


Specification  of  Protocol  and  Interconnection 
Part  1  —  Introduction  ISO  DP  8650/1 
Part  2  —  Basic  Kernel  ISO  DP  8650/2 

Part  3  —  Commitment,  Concurrence,  and  Recovery  ISO  DP  8649/3 

Manufacturing  Automation 

Use:  Manufacturing  Automation  Protocol  (MAP) 

Spec:  Working  Draft 

Office  Automation  and  Workstation  Support 

Use:  Technical  and  Office  Protocol  (TOP) 

Spec:  Working  Draft  Specification  Rev  X.5.0  of  9  September  1985 

Full  Screen  Terminal  Support 

Use:  Virtual  Terminal  Protocol  (VTP) 

Spec:  IPS-OSI  Virtual  Terminal  Basic  Class  Service 
Part  1  -  ISO  DP  9040 

IPS-OSI  Virtual  Terminal  Basic  Class  Protocol 
Part  2  -  ISO  DP  9041 

Restrictions:  Use  only  in  local  environments,  not  across  long-haul  networks. 

Do  not  use  as  a  basis  for  interoperability  or  distributed 
processing.  Use  regular  data- transfer  facilities  (above). 

PRESENTATION  LAYER 

All  required  functions  provided  under  CASE  above. 

SESSION  LAYER 

Use?:  Basic  Synchronized  Subset  ( BSS) 

Spec:  IPS-OSI  Session  Service  Definition  —  ISO  IS  8326 

IPS-OSI  Session  Protocol  Specification  —  ISO  IS  8327 

TRANSPORT  LAYER 

Information  Systems 

Use:  Transport  Protocol  Class  4  (TP  4) 

Spec:  IPS-OSI  Transport  Service  Definition  —  ISO  IS  8072 


IPS-OSI  Transport  Protocol  Definition  —  ISO  IS  8073 
Formal  Description  of  Transport  —  Working  Draft 


Tactical  Systems 

Use:  Transport  Protocol  Class  0  (TP-0) 

Spec:  Same  specification  as  for  information  systems 

NETWORK  LAYER 

Internet  Addressing 

Use:  Internet  Protocol  (IP)/Internet  Control  Message  Protocol  (ICMP) 

Spec:  Network  Service  Definition  —  ISO  IS  8348 

Addendum  1  —  Connectionless-Mode  Data  Transmission  —  ISO 
IS  8348/ AD  1 

Addendum  2  -  Network  Layer  Addressing  -  ISO  IS  8438/D  AD2 
Protocol  for  Providing  Connectionless  Network  Service  —  ISO  IS  8473 

Addendum  1  —  Provision  of  the  Underlying  Service  Assumed  by 
ISO  8473  ~  ISO  IS  8473/DAD  1 

Addendum  2  —  Formal  Description  of  the  Specification  of  an  Internet 
Protocol  -  ISO  IS  8473/PDAD2 

Internal  Organization  of  the  Network  Layer  —  ISO  DP  8648 

Interaction  Between  Networks/Gateways 

Use:  Exterior  Gateway  Protocol  (EGP) 

i  Spec:  Intermediate  System  to  Intermediate  System  (IS-to-IS) 

I  Protocol:  Draft  Network  Layer  Protocol  for  the  Exchange  of  Routing 

I  Information  Between  Intermediate  Systems 

I  Accredited  Standards  Committee  (ASC)  X353.3/85-224 

I 

Interaction  Between  Hosts  and  Gateways 

Use:  Host-to-Gateway  Protocol  (HGP) 

Spec:  End  System  to  Intermediate  System  (ES-to-IS)  Routing  Exchange 
.  Protocol  for  use  in  Conjunction  with  ISO  8473.  ISO  TC  975C6N4053. 


DATA  LINK  LAYER 


Packet- Switched  Network  Access  [Including  Defense  Data  Network  (DDN)] 

Use;  DoD  X.25 

Spec:  DoD  parameters  used  with  CCITT  Recommendation  X.25,  Interface 
between  Data  Terminal  Equipment  (DTE)  and  Data  Communication 
Equipment  (DCE)  for  Terminals  Operating  in  the  Packet  Mode  on  Public 
Data  Networks  —  ISO  DIS  8208. 

Local  Connections 

Use:  Institute  of  Electrical  and  Electronic  Engineers  (IEEE)  802.2  Type  1 
Class  1 

Spec:  IEEE  Project  802  Local  Area  Network  Standards  —  IEEE  802.2 
Logical  Link  Control  —  ISO  DIS  8802/2 

PHYSICAL  LAYER 

Campus  Backbone 

Use:  Present  through  1988  —  Broadband 

1988  and  beyond  —  Fiber  Distribution  Data  Interface  (FDDI) 

Spec:  Physical  Layer  Protocol  X3T9.5/83-15 

Token  Ring  Physical  Layer  Medium  Dependent  X3T9. 5/84-48 
Token  Ring  Medium  Access  Control  X3T9.5/83- 16 
FDDI  Hybrid  Ring  Control  —  Working  Draft 
FDDI  Token  Ring  Station  Management  —  Working  Draft 

Intra-Building 

Use:  IEEE  802.5  —  Token  Ring  (Cable  or  Twisted  Pair) 

Spec;  IEEE  Project  802  Local  Area  Network  Standards  —  IEEE  802.5 

Token  Passing  Ring  Access  Method  and  Physical  Layer  Specification  - 

ISO  DIS  8802/5 

! 


DoO  PROTOCOL  STANDARDS 

DoD  has  standardized  protocols  as  MIL-STDs.  The  Navy  allows  use  of  the 
following  DoD  protocol  standards: 

Applications  Layer 

Pile  Transfer 

Use:  File  Transfer  Protocol  (FTP) 

Spec:  MIL-STD1780 

Electronic  Mail 

Use:  Simple  Mail  Transfer  Protocol  (SMTP) 

Spec:  MIL-STD1781 

Asynchronous  Terminal  Support 

Use:  TELNET 
Spec:  MIL.STD1782 

Restrictions:  This  should  be  used  for  interoperability  with  existing  systems 
only.  Use  of  this  protocol  is  discouraged. 

Presentation 

(none) 

Session 

(none) 

Transport 

Use:  Transmission  Control  Protocol  (TCP) 

Spec:  MIL-STD1778 

Network 


Use:  IP  and  ICMP 
Spec:  MIL-STD1777 


Lower  Levels 

Use:  DDNX.25 

Spec:  Defense  Communications  Agency  (DCA),  DDN  X.25  Host  Interface 
Specification,  December  1983 
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APPENDIX  B 


ENGINEERING  DRAWING  MANAGEMENT  INFORMATION 
AND  CONTROL  SYSTEM  (EDMICS) 

DATA  COMMUNICATIONS 


Volume  Requirements 


DATA  COMMUNICATION  REQUIREMENTS  FOR  PRIMARY  REPOSITORIES 
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COMMUNICATION  REQUIREMENTS  FOR  PRIMARY  REPOSITORIES  (Continued) 


DATA  COMMUNICATION  REQUIREMENTS  FOR  SECONDARY  REPOSITORIES  (SHIPYARDS) 


DATA  COMMUNICATION  REQUIREMENTS  FOR  SECONDARY  REPOSITORIES  (SHIPYARDS)  (Continued) 


DATA  COMMUNICATION  REQUIREMENTS  FOR  SECONDARY  REPOSITORIES  (NARFs  AND  NESECs) 

(Continued) 
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DATA  COMMUNICATION  REQUIREMENTS  FOR  SECONDARY  REPOSITORIES  (OTHERS) 


liH  too 


DATA  COMMUNICATION  REQUIREMENTS  FOR  SECONDARY  REPOSITORIES  (OTHERS)  (Continued) 
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APPENDIXC 

ARMY  COMPUTER  AIDED  LOGISTICS  SUPPORT  (CALS) 
INTERSITE  DATA  FLOW  MATRIX 
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U.S.  ARMY  ARMAMENT,  MUNITIONS,  AND  CHEMICAL  COMMAND  (AMCCOM)  (Continued) 
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U.S.  ARMY  MATERIEL  COMMAND  (AMC) 
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TABLE  C-6 

U.S.  ARMY  BELVOIR  RESEARCH  &  DEVELOPMENT  CENTER  (BRDC) 


•iLC 

•iMC 

AMCCOM 

-rvISAA 

.•.NAH 

AySCOM 

CAC 

CCAO 

I  ,'nf  r,»(  [ nr 


TABLE  C-7 

U.S.  ARMY  COMMUNICATIONS-ELECTRONICS  COMMAND  (CECOM) 


Enqine«»rinq 

dr-»wtnq 


3.500 

241  b69 

2  bC  1 

80  89  1 

2‘ 

3.500 

;  ’5 

3.500 

1  15 

242  295 

2.971 

'80.891 

104  41 

n  800 

34,150 

208  65 

520  640 

222  40C 

1  32  200 

220  41 

8  049 

648 

708 

1  53 

296  3  72 

6  559  068 

331.018 

3.564  61 

2  250 

7  200 

3  81 

-  ■  )‘r,(  ':)M 

S  980 

0  21 

*•  t  8r  icj-} 

2  250 

0  04 

‘•t  C  irson 

2.490 

0  11 

f  t  Gordon 

531.199 

648 

1  648 

213  76 

ft  Kno* 

180,495 

6.556,369 

321.600 

3.530  21 

Ft  Lewis 

29,600  ' 

14,800 

14,800 

16  41 

l8AD 

1.332.680 

6  544  997 

634  815 

3.733  79 

itA 

3  500  ' 

0  IS 

;  f  A(,> 

2  1 2  848  1 

MiS 

•  /9  400 

•  0 1 2  11 

MiC')M 

3  5^:0 

;  IS 

MH5« 

454  980 

•i  'ly 

'ly 

2  2  S' 

M/Al' 

y  /f'  y  /  ' 

S2  M' 

•  ;/  y 

y ;  s ; 

j 

y  j  1  :/0 
<  S'/O 

yhH  'ih/ 
1  lyo  'J'K 
yn  ;y'’ 

J  ’J«0 


AFt  C 

A1  c 

AMf 

;  AMCCOM 
^  ---MS.'**. 
..rjAi  • 

Avsco^y1 

CAC 

CCAO 

Conr»l  print 

ContrAttOf 

DA 

OESCOM 

OLA 

DCSC 

i-ORSCOM 
ft.  8f<tqq 
Ft.  Carson 
Ft  Gordon 
Ft  Kno* 

Ft  Lewis 

lbao 

LEA 

leAo 

MICOM 

*,1«SA 


soo 

14.909 

180.475 

29.600 

1.332,680 


r'-jinr'of  nr^ 

dr  »A  ''  z 


■'  bO  ■  •  SO  89  ' 


2.971  ’80.891 


28.192  22  402 


17.618  16830 

7,200 


648 
6.566.369 
14.800 
6.544  997 


TABLE  C-8 


U.S.  ARMY  COMBINED  ARMS  CENTER  (CAC) 


CAC 

from 

tpKl 

AMCCOM 

1300 

AvSCOM 

3300 

CECOM 

3300 

•;llCOM 

3300 

TACOM 

•0,300 

'iSAiCS 

CORPUS  CHRISTI  ARMY  DEPOT  (CCAD) 


CCAD 

t  3 

to.t 

f  nc^inponnq 
3r.»wirq 

■  1 

•llustr  »t'' 

•1iilii>n 

bits 

CCAD 

from 

’•'•t 

wgm 

iiluSt' 

•^1  1 1  r 

R'fS 

AVSCOM 

7M.990 

114.329 

S1,447 

1  7S 

AVSCOM 

97S.240 

'  3S'  829 

&4b.44  7 

V064  20 

CECOM 

24^,295 

2,971 

180.891 

104  40 

CECOM 

242  29S 

2  •* 

<80.891 

’04  40 

CDA 

CDA 

286. 74S 

■  sOC 

244  99  3 

’  38  40 

MiCOM 

6S.461 

481 

S8.I53 

32  80 

MICOM 

bS.4bi 

18' 

S8.1S3 

32  30 

'A(,  APC 

TAG, APC 

•181  Sbb 

sn  2'fS 

39  b0  3 

*>9  S.) 

Notm:  Alin  umDPrs  .ir»»  •)«  m  O  is.n  ni  tnir  .  nnot^v  to  O0  (3*»< .d#*d 


TABLE  C-10 

DEPARTMENT  OF  THE  ARMY  (DA) 


W W  W  W  W  W '  ’V'*  W  V  V  "J«  \'<  ’WW  V«  V'  V(  VI  "JT'JI  *JI  ■>’  ■  V  T%"«.'.’“  li'^  VT  I 


TABLE  C-14 
FT.  GORDON 


ft  Gordon 

to 

feit 

Engineering 

drawing 

Illustration 

BiHiOn 

bits 

ft  Gordon 

from 

Tent 

Engineering 

arawinq 

llustr.uion 

Riihon 

bits 

CECOM 

14.909 

648 

648 

1  ^9 

■ 

S3t  *99 

6.18 

1)48 

r  i  ’h 

Mofe.'  All  numbers  nre  on  .mnu'ii  basis  A  blank  'onnoiPs  ( )  be  ae^  loeo 


TABLE  C-15 
FT.  HOOD 


Mof«.  All  numbers  are  on  an  annual  basis  A  blank '•onnotes  10  be  decided. 


n  HOOd 

to 

te«t 

Engineering 

drawing 

Illustration 

Billion 

bits 

1  t  '^u'Td 

from 

lent 

tngine.iring 

arawiiig 

iiustration 

8 1 1 1 1 n 

bits 

AMCCOM 

fROSCOM 

4,900 

600 

0  5t 

AMCCOM 

TftOSCOM 

/b.ns 

80 

600 

SI 

3  52 

0  03 

i 

& 


I 


'i 


'A 


i 


i 


Vi 


‘J 


p 


5i 


TABLE  C-17 


FT.  LEWIS 


i-t  Lewis 

to 

Text 

E  nqmeermq 
arawmq 

■llustr^tion 

Billion 

bits 

ft  Lewis 

from 

Text 

t  Oij'  f'eon  nq 

OfaA.r'..; 

--  6 

AVSCOM 

'^.000 

C  ST 

AwSCOV 

12.000 

.  s  ■ 

CECOM 

29.600 

14,800 

14  800 

1b  41 

CECOM 

29.600 

’4  800 

1  wc.; 

IVtiCOM 

J.bSi 

1217 

2.434 

2  02 

MiCOM 

3.bS- 

/ 

TACOM 

1  bSi 

’.271 

2.4  34 

2  02 

TACOM 

3  bSi 

■  2  /  ' 

TROSCOM 

iROSCOM 

30 

Vote;  All  numbers  on  ,40  nnnur^i  A  oUnx  connotes  to  be  decided 


TABLE  C-18 
FT.  RILEY 


Ft.  Riiev 

to 

Teit 

tnijjineertnq 

dr/iwinq 

iilust^it'on 

Biiiion 

bits 

ft  Riley 
from 

Text 

f  nqineer mg 
drewinq 

'MustMtion 

3,il 

bits 

TROSCOM 

TROSCOM 

80 

SI 

:  03 

JVor«;  All  numbers  <»re  on  .»n  .*nnu.«l  O'^Ms  A  oi  mu  -  nn  tes  to  be  decided 


TABLEC-19 

FT.  WINGATE  DEPOT  ACTIVITY  (FWDA) 


‘  YVDA 

Hilli'in 

bits 

— 

{  ' 

-MreOM 

/s  2S/ 

'lb' 

S3  3/S 

312  3 

AMf  r(3M 

'S  -vs 

’.)/  -MS 

'«b  • 

•  .  ( 

'/ir  OM 

b/  MH 

2  !  ( 

S3  MjH 

if)  20 

MllOM 

/-1 8 

! 


TABLE  C-20 

U.S.  ARMY  DEPOT  SYSTEMS  COMMAND  (DESCOM) 


DESCOM 

to 

TPKt 

E  ngineering 

dr^iwing 

o 

im 

rp»t 

(  'll jir»p»»r  1  f'c  j 

dM.V  ^'3 

.s. 

r 

AMCCOM 

'b  883 

1. 1  39 

>39 

■  S  •’ 

AMCCOM 

■C  3  .04b 

/ !  b  )9 

-84 

It/.' 

AvSCOM 

■2  8/8 

S43 

S/4 

■  ■? 

A  .  SCOM 

491  3’ 3 

•  /94  ;4  j 

'.99  ^8.8 

•9 : 

CFCf^M 

/’A  COO 

’  /  618 

lb  830 

HO 

C[  COM 

/96  iJ! 

Jb8 

i  .3  ■  .  ■  8 

•j  a;r.’ 

b  4  m 

■  8S1 

3  2?>i 

i  to 

V  {  ov 

394  S  O 

•  -IS  iS 

*iC  AOj 

n  849 

3.04b 

3.34S 

4  /C 

^c-. 

3  3  849 

.  ..'.h 

'ACOM 

^8  '44 

'  /’b) 

<',S09 

S  A9 

•ACOM 

31  3.81b 

JbH  bH 

.  :■  ' 

i-,:-,  r. 

'^^(JSCOM 

■S  /b8 

b89 

t)  14 

’  33 

'ROSCOM 

51.969 

84  '89 

’  -  .'H 

19  30 

Note:  Ail  «'■«*  »n  bHSis  A  Di'inii  connot'^s  to  Oe  decided 


TABLE  C-22 

LEXINGTON-BLUE  GRASS  ARMY  DEPOT  (LBAD) 


LBAD 

to 

Text 

Engineering 

drawing 

Illustration 

Billion 

bits 

LBAD 

from 

Te»i 

Ef'qineennq 

drawing 

ii-usirauon 

8'  lion 

AMCCOM 

/S.423 

an 

53.275 

30  90 

AMCCOM 

75  42  3 

8'  • 

53,2/5 

30  90 

AVSCOM 

46 

22 

001 

AVSCOM 

46 

22 

0  O' 

CECOM 

1.332.600 

6.544,99/ 

634.015 

7  24 

CECOM 

1.332  680 

6,544  '^9  7 

634  315 

'  24 

COA 

CDA 

306.198 

3H8  ■  )S 

5 ;  ■  <H 

•:89  90 

TACOM 

426.390 

387.910 

219  022 

3  31  30 

lACOM 

4  76  390 

n8i  T  ' 

/  9  022 

33  •  OO 

TAG  APC 

TAG-APC 

360.190 

•I'll: 

■  -9  40C 

'28  50 

TROSCOM 

53.932 

377 

50.688 

28  44 

TROSCOM 

53.932 

SO  b88 

28  44 

Mote;  All  numbers  are  on  an  Annucil  basis  A  blank  connotes  to  be  decided 


TABLE  C-23 

MAINZ  ARMY  DEPOT  (MZAD) 


t  n<jineer(nq 
drawing 


rjtllion  MZAO 

bits  ♦rom 


:  nQinep'ing 
drawing 


AMCCOM 

crcoM 

COA 

MICOM 

TACOM 

TAG^APC 

tROSCOM 


AMCCOM 

cecoM 

COA 

MiCOM 

fACOM 

TAl,/APC 

TROSCOM 


m  b/f 
2f0.2n 
a68,8i  i 
.144  b99 
I  i IS. 46. 
1.416  988 

S42  242 


3V/4} 
.1  /4J 
i8H  10S 
i.'iS0,342 
S.3S7  97S 


bO  ,  4.J 
182  J ji 
SS9  /8b 
/2S  690 
2.2  34  -b' 
212  882 
‘tO  683 


Note:  All  numbers  »rp 


TABLE  C-24 


•  I*- Ja- -41'  ^t«‘, 


U.S.  ARMY  MATERIEL  READINESS  SUPPORT  ACTIVITY  (MRSA) 


MRSA 

to 

r#»«t 

i  nqinf‘«‘rin(5 

3r  iwinq 

B 

OitV 

MRSA 

from 

tp.( 

.1  ^s:'  It.'  '' 

H  ■'  ■ 

AMC 

1SS 

4 

3  OJ 

AMC 

AMCCOM 

;oa 

0  01 

AMCCOM 

3  1  -iSC 

j‘i  :.:s 

■i 

AMSAA 

;  000 

0  08 

AMSAA 

AVSCOM 

/  900 

•  ■}7S 

■  9/S 

/  ib 

AVSCOM 

.  ;  •••■. 

.  '1  . 

1  .  ; 

CECOM 

A40.S00 

•9  60 

CtCOM 

IS  1  99C 

■ 

Contractor 

Contr^tor 

;9C 

*1 

fCRSCOM 

190 

10 

4 

0  0^ 

f  ORSCOM 

4  S6/ 

LAO 

;o 

10 

4 

0  31 

l  AO 

LEA 

^.000 

:  39 

lEA 

MiCOM 

400 

0  0/ 

\1iCOM 

30  jSC 

i  JZ 

TACOM 

soo 

iiO 

3^0 

0  Jb 

'ACOM 

31  b8C 

9HS 

S40 

i  : 

TRADOC 

’0 

10 

4 

fRAOOC 

'8C 

•n 

b 

: 

'ROSCOM 

18  497 

10.800 

'>4  4/ 

'RQSCOM 

»/ ;// 

4  U 

It*. 

Note  .4II  'iymOAr«,  .4f<»  jn  in  inniu-»t  D-iSi'i  ••  O  .•■‘n  '  0^  0*‘-  0*‘0 


TABLE  C-2S 

U.S.  ARMY  MISSILE  COMMAND  (MICOM) 


MICOM 

foit 

1  ws'f  »l  ■» 

MiCOM 

♦r  m 

... 

■1  '  ■' 

AM  C 

/SO 

-  ,4 

-I .  » 

"•>  '• 

Al  C 

3, soo 

■  "1 

•'•1  ■. 

AMC 

JJ.0^1 

2  89/ 

3  .34 

;  59 

••.M( 

1  2  i'. 

AMCCOM 

i  'S 

AMCCOM 

3  . 

AMSAA 

3. soo 

;  IS 

.‘.MSAA 

ANAO 

444  099 

1  9S0.46S 

/;s  sio 

’  389  4- 

ANAt- 

544  )99 

'  'js-;  tbS 

•.'S  S',- 

iM9  ■ 

AVSCOM 

ArfSCOM 

3  ■>>}  1 

..  S 

CAC 

3  son 

<  AC 

rr.,1. 

l.s  5h  ! 

4H1 

SH  S3 

1/  S’ 

1  f  A|. 

«•  .  1<> 

•  S 

^  . 

Cl  COM 

3  ^00 

J  *s 

•'»  COM 

3  ->  i  : 

C'  nfr  |.  T,  ,,f 

1  ’T  Ml 

/K  /  /  / 

/  ir.H 

■lt  •*. 

r  fit'i.  •  ' 

•  ISS  .Ss-> 

*3  M.l  / 

19  :Mh 

.■  t  :■ 

:  <\ 

M  ^4S 

■  390 

300 

ih 

1 

.  { 

M  SCOM 

394  sn 

1  9S'  9ST 

b/  )  -MS 

1  3S9  9’ 

I  *.(  OM 

b  ;  39 

H'y  ' 

1  .MM 

{  • 

'  il  “ 

/so 

»  04 

1  1  A 

■  nt'M 

.M': 

t 

.  ■  M 

TABLE  C-25 


U.S.  ARMY  MISSILE  COMMAND  (MICOM)  (Continued) 


MiCOM 

to 

r*»«t 

i  nqioppnnq 
dr.<winq 

Illustration 

BiHion 

bits 

MICOM 

♦rom 

'®»t 

t  nqmeprmq 
dr.jwmg 

Illustration 

Billr;.n 

D-tS 

‘ t  Hr^qq 

/SO 

3  04 

1  t  Br.^(j4 

i-t  Carson 

)00 

0  02 

•  t  C  »fson 

too 

I  D2 

rt 

'Q,')A8 

190 

510 

0  32 

H  ^  nc 

->  .If-l 

95 

'  t  ;  ''vVis 

i  'iS  ’ 

1.217 

2.434 

2  02 

1  t  l  O  -AI'S 

i  ♦)•) ' 

■  2-  / 

/  4  34 

/  :2 

<-  WDA 

b/748 

273 

53.108 

30  23 

1  WDA 

h'  '48 

2/3 

5  3  ’OS 

31  2  ' 

LBAQ 

LBAD 

LtA 

3.500 

0  15 

LEA 

L£AO 

444.137 

1.950,483 

725.510 

1.38941 

LEAD 

259  637 

483 

77.5'0 

so  92 

MR$A 

30.050 

15.420 

60 

921 

MRSA 

100 

J  02 

MZAD 

444.669 

1.950,482 

725.690 

1 . 389  4 1 

MZAD 

260,169 

482 

//,690 

'0  91 

NAOA 

67.748 

273 

53,108 

30  21 

NAOA 

67/48 

273 

53,108 

33  2  1 

Navy 

750 

0  04 

Navy 

750 

0  04 

NCAD 

64.752 

1.081 

161  1/4 

85  81 

NCAD 

64  752 

1,081 

161.1  74 

85  81 

NC.B 

600 

003 

N(iB 

300 

0  02 

OTf  A 

3.500 

)  IS 

on  A 

KRAD 

:,233.m 

7.509,279 

ibO  '90 

I  06491 

RHAD 

450.6 11 

311 

77,690 

S9  01 

SAAO 

965,326 

1.951.485 

770.708 

1.43401 

SAAO 

800.828 

1.485 

122,708 

92  44 

seAo 

988,850 

1.951.475 

770.708 

I  4  36  0  > 

5EAO 

804.350 

1.475 

122.708 

97  61 

SHAO 

64.752 

1.081 

161  174 

85  81 

SHAD 

64,762 

1,081 

161.174 

85  81 

SIAO 

443.715 

1.950.273 

725  510 

1.3890' 

SIAO 

259.215 

273 

77,510 

50  81 

ssc 

600 

003 

ssc 

0 

0 

0  02 

SvOA 

67.748 

273 

53.108 

30  20 

SVOA 

67.748 

2/3 

53.108 

30  20 

rA(i 

649.816 

2.310 

h9  566 

115-18 

:A(, 

fRADOC 

17.325 

300 

300 

1  04 

niAi'iOC 

■  920 

1 ,080 

J  tj3 

TCOM 

16.725 

300 

lOO 

I  01 

'FCOM 

•A(()M 

'ACOM 

0  300 

;  4.1 

'I  AC.’ 

985.328 

1.951.485 

7/0  708 

1.4*4  01 

r(  AO 

800  828 

1  185 

122  '08 

)/  1.1 

193,572 

983 

n  53/ 

18  34 

'OAD 

381  520 

■  950  48  3 

t>h7  382 

'  357  ;  1 

Ml 

143,715 

1.950.273 

725,510 

1  389  01 

ijMDA 

259  2i»> 

2  ■  t 

.’  /  5 1 

-.18' 

^jSAKI  i|R 

■  ISAHEUR 

100 

:  ..:2 

Note.  •'•II  f'lirnh'^rs  irp  >)n  <nnuHl  b-iMS  A  bMoN  c /.nook's  lo  D**  do^idPd 


I 

I 


t 

i 


I 

I 

i 

I 

('  If) 


TABLE  C-26 

U.S.  ARMY  NATICK  RESEARCH  &  DEVELOPMENT  CENTER  (NRDC) 


Engineerinq 

drawing 


Billion  NROC 

bits  ♦rom 


Engineering 

drawing 


AMC 

Contractor 

FORSCOM 

LABS 

LEA 

TFCQM 

TECOM  Tf^st 

TRADOC 

rflOSCOM 


AMC 

Contr«itl.,’ir 

FORSCOM 

labs 

LEA 

TfCOM 
TECOM  rest 
TRAOOC 
TROSCOM 


Note:  All  numbers  are  on  an  annual  basis  A  blann  connotes  to  be  decided 


TABLE  C-27 

NAVAJO  DEPOT  ACTIVITY  (NADA) 


NADA 

to 

rent 

Engineerirsq 

drawing 

lltustration 

BHIiOn 

bits 

NAOA 

from 

Text 

Engineering 

drawing 

Illustration 

Billion 

bits 

AMCCOM 

;5,725 

961 

53.375 

31  2i 

AMCCOM 

757^5 

961 

53.375 

J1  23 

CDA 

COA 

127  395 

n075t 

62  10 

MiCOM 

67. /48 

2n 

53.108 

30  20 

MiCOM 

b7  M8 

273 

53,108 

30  20 

Wore;  All  numbers  are  an  annual  basis  A  blann  i  onrsotes  to  be  der.ded 


TABLE  C-28 

NEW  CUMBERLAND  ARMY  DEPOT  ENCAD) 


Enginnerifsg 

drawing 


AMCCOM 
AVSCOM 
CFCOM 
SCOM 
ni  SC 
MiCOM 
iAC(jr/i 
IHOSCOM 


AMCCOM 
..ViS<  ()M 
'  I  COM 
■  i»  SLOM 
1 1|  St 
Mit  f)M 
( )M 

'Mt)S(  f)r.i 


hS  HM) 
V  b/' 
/'i '  {)/<} 
\  \  H*l'l 

I  ftw  aso 

l>.l  -s/ 
l/t.  MH'I 
S  {  u  /•. 


TABLE  C-29 

U.S.  ARMY  OPERATIONAL  TEST  &  EVALUATION  AGENCY  (OTEA) 


Engineering 

drawing 


AMCCOM 

AvSCOM 

CECOM 

MlCOM 

TACOM 

TROSCOM 


IVote;  All  numbers  are  on  an  annual  basis  A  blank  connotes  to  be  decided 


OTEA 

from 

Tent 

AMCCOM 

3.500 

AVSCOM 

3.500 

CECOM 

3.500 

MICOM 

3.500 

tacom 

13.300 

TROSCOM 

I.OOC 

t  ngineecng 
drawing 


TABLE  C-30 

U.S.  ARMY  ORDNANCE  CENTER  &  SCHOOL  (OC&S) 


AMC 

Contraaor 
FORSCOM 
TST  Agency 
TRAOOC 


AWC 

Contractor 
FORSCOM 
TST  Agency 
TRAOOC 


IVote;  All  numbers  are  on  an  annual  basis  A  blank  connotes  to  bede-  >ded 


TABLE  C-31 

PUEBLO  DEPOT  ACTIVITY  (PUDA) 


*.p/rc()M 
roA 
MlCOM 
’Af  f)M 
'  A(,  .-.kr 
'Most  OM 


I  nqinp«»r.ni) 
dr  iwini-l 


H'liion 

Oils 

PIlOA 

fr.>m 

fe»t 

iH  'R) 

AMt  roM 

•hU  JA8 

T'A 

♦>5/  /*f5 

:  M'l 

M!(  or/ 

AAA  ’ll 

>  »0 

TACOV 

IH/  S3S 

’.‘.t  Ai-r 

Has  hl5 

.  M  •  •• 

•hoSC  r)r/ 

S  I  'U  A 

TABLE  C-32 


RED  RIVER  ARMY  DEPOT  (RRAD) 


RRAD 

to 

Text 

Enqinpennq 

dTAwinq 

illustr  »ton 

Billion 

bits 

RRAD 

from 

text 

EiiqinnAfinq 

drawing 

illustratii'n 

■ 

AMCCOM 

161, 9A1 

6.610 

bO  244 

1/  fO 

AMCCOM 

161.941 

6.610 

60,244 

3  ^  .*0 

CKOM 

269,96/ 

4  591 

■62  jr 

•(!/>] 

CtCOM 

269,967 

4,591 

’82  33' 

'  0  '  '  0 

CDA 

CDA 

886.813 

388.105 

559  786 

52  3  00 

rviiCOM 

•iSO.bl  1 

1 '  ' 

/  /  69C 

59  OZ 

MiCOM 

3.233.11  1 

>  509  2/9 

'60  ’90 

4  >>4  90 

"ACOM 

661.661 

4  10  245 

228  b/  J 

}55  20 

rACOM 

1.218.941 

5  356  '129 

2  234,16' 

3.9  39  50 

TAG-APC 

TA(,  APC 

285.801 

:  M9 

'72,668 

6.  '84  20 

TftOSCOM 

54,114 

469 

SC  *j8H 

28  50 

TR05C0M 

54.114 

■169 

5C  b88 

28  50 

iVof«;  All  numbers  on  An  **nnudl  A  bun«  ^nnot^s  to  be  oe<ide<l 


TABLE  C-33 

SACRAMENTO  ARMY  DEPOT  (SAAD) 


SAAD 

to 

r«xt 

Engineering 

drawing 

Illustration 

Biil'on 

bits 

SAAD 

from 

text 

Hfl 

■ 

AMCCOM 

H7,305 

4.141 

45,275 

39  60 

AMCCOM 

344,805 

1 

•  j  1  1 

IS  /25 

'8  30 

CECOM 

9/3.168 

3.425 

148.476 

118  90 

cecoM 

1.120918 

654  8/S 

4S5  3  ’S 

3  63  3  00 

CDA 

CDA 

392.664 

205 

340  764 

'91  20 

MiCOM 

800.284 

1,483 

122.708 

97  44 

MiCOM 

985,324 

'  9S1  483 

7/0, '08 

'.4  34  CO 

TAG  APC 

tA(,  APC 

1.836  /22 

3  5.: 

299  s;' 

2  32  60 

fROSCOM 

'5/  /39 

922 

22  380 

19  00 

IROSCOM 

’  h8  9  1 9 

H.i 

26  -3  7  2 

•vl  ,■  ) 

More;  Ail  numo»=*fs  ir*™  '  ,n  m  *nnuAi  Dams  A  binnk  onnot^s  to  bn 


TABLE  C-34 

SAVANNA  DEPOT  ACTIVITY  (SVDA) 


Svf.'A 

V) 

lo.t 

■ 

■ 

i.MCCOM 

7S  /2S 

961 

5  3  /  7S 

31  23 

..M(  (  OM 

/*■  //S 

It, 

'  ( 

MiCOM 

6/,/48 

2/3 

5  3  -OH 

30  2  3 

MKOM 

»w'  /.:h 

.• '  1 

•  1  m 

TABLE  C-35 


SENECA  ARMY  DEPOT  (SEAD) 


SEAD 

to 

Te>«t 

E  nqinppfioq 
dr.i^vinq 

;!l  .sfr.Jt'O'' 

aiHton 

bits 

StA'i 

*T\tm 

'•‘.t 

H 

B 

RH 

O'  rs 

amccom 

CDA 

A.^^bSi 

4  !SJ 

98  va 

/o  ;4 

AMCCOM 

CD  A 

UC  ’‘'• 

->41  lh4 

Ih 

”■  1 

*•  . 

•)b  v» 

.  /  ■  S-'S 

'  ;9 

MiCOM 

JQ4  jso 

•  4/S 

^^2/08 

9/  bO 

M'COM 

988. 8S0 

■  • 

•'  8 

4  <h  . 

'ACOfv^ 

’AC.  APC 

-18^  S4S 

j')n  9/0 

_ 1 

^19022 

iU  80 

*AfOM 

•«(.  Ai'f 

1 

48^  S4S 

849 

'9 

s 

!  “ 

Mora;  -kii  numD*»f>  4r*»  .  n  m  «r>ou^l  o-^S'S  •!  bUnh  v)nn»  tes  to  0^  O**'  Of'O 


TABLE  C-36 

SHARPE  ARMY  DEPOT  (SHAD) 


smaq 

ro 

>«t 

E  riqin*»<»rioq 

Illustration 

Bits 

'<»»t 

1 

Jf  A  n  j 

'uslf  <1'-  '■ 

AMCCOM 

bb  8'0 

■04 

90b 

^9  90 

AMCCOM 

nS  810 

•(M 

s;  90b 

.'9  9 : 

A\,SCOM 

’  S49 

t.n6 

S  JO 

AVSCOM 

i;,8;/ 

'  S49 

/  fib 

s  3: 

CECOM 

V4t  o;o 

J  ibO 

180  69t 

104  00 

CECOM 

Mt.O/O 

/  3b0 

'8C  891 

•■)4 

DESCOM 

iJ  849 

)  04h 

3  34S 

4  /o 

oescoM 

33.849 

I  ■  .Jh 

3  34S 

4  f'. 

ruSC 

88'  WS 

J9n  bbs 

b/0  S/S 

S80  80 

OLSC 

i.;w,8so 

/»•  1 3;) 

'  34‘  ’SC 

'  b's  /: 

MiCOM 

->4  /S; 

C8' 

'h'  ’  /4 

8S  80 

MiCOM 

b4  /s; 

,8' 

■b'  '  /4 

8S  8: 

■A  COM 

4  /b.889 

(88  S' 

//<}  S  IS 

331  9C 

'ACOM 

•i/b.889 

<H»  S 

.'/r  ^  ,s 

H'  '*■; 

•4CJS(’()M 

1  <  ')/h 

_ 1 

f.HH 

/8  44 

'HOSCOM 

>  3  9  'h 

,  K  ;4 

Mor«  I  OufriO#*''>  ’<■'  If'  tf'fMj  *•  0  isi‘i  f*  '  f  0*» 


TABLE  C-37 

SIERRA  ARMY  DEPOT  (SI  AD) 


AMfrOM  iSb-lSO 

r  A 


Mlustr  »ti'  >n 

9i.li..r 

bits 

M),  •  fh 

38  /O 

t  i  >M 

(.[•A 

•//,93S 

n  S') 

SO  80 

MICOM 

;.i  1  /  -s 

A(,  .\i>r 


A»’( 


H-V»  fi'S 


TABLE  C-38 


U.S.  ARMY  TANK-AUTOMOTIVE  COMMAND  (TACOM) 


TACOM 

to; 

Text 

Enqine^finq 

drawing 

illustration 

Hiiiion 

pits 

TACOM 

trom 

'f»«t 

Bn 

AFLC 

286.933 

12  32 

286  933 

ALC 

to. 300 

3  44 

AMC 

34.921 

2.265 

3  542 

4  45 

AMC 

1  '  MS 

i/s 

AMCCOM 

3.S00 

0  15 

AMCCOM 

3  500 

AM^AA 

20  '2S 

524 

524 

1  39 

AMSAA 

ANAD 

1  22’.942 

5  358. 1C2 

2  234  '03 

3,940  31 

ANAO 

'  22*  94.- 

••  3‘-" 

AVSCOM 

i  SOO 

0  35 

AVSCOM 

3  s.’o 

CAC 

10.300 

0  44 

CAC 

CECOM 

10.300 

0  44 

CECOM 

Comi  print 

120,080 

20.520 

3  800 

13443 

Comi  print 

Contractor 

465,991 

1  595,2  1  / 

b  2  34 

849  10 

Contractor 

29/ 2/ ' 

.  -'H 

OA 

12.249 

844 

904 

'  4» 

OA 

952 

3/11 

OESCOM 

813.816 

4  968  68' 

2.024  4  12 

3bi6  33 

Df  SCOM 

/8  '  14 

■  ^h' 

DlA 

286  933 

'2  '2 

01  A 

28b  9  3  3 

Disc 

UISC 

/8b  93  3 

‘ORSCOM 

1,104 

320 

120 

)  )i 

lb. 

1/'' 

!jra<5q 

286.933 

'2  12 

rt  8r.+og 

<=1  Carson 

152 

0  01 

M  Carsvn 

H  Knot 

19.829 

f,824 

524 

2  04 

M  Kno« 

9  824 

5/4 

*  t  L«»WVlS 

3.65t 

1.21  7 

2  434 

2  02 

Et  Lewis 

3  bS' 

■  /■  ' 

l8AD 

4  76.390 

387,910 

219  022 

331  01 

IBAO 

17b  390 

30/  9'0 

it  A 

10,300 

0  44 

1 EA 

■  ^Af. 

'22.409 

5  357  929 

2.234  164 

3.940  31 

i-Ead 

bbS  329 

1  ‘  ■  %  2  9 

MiCOM 

'0.300 

0  14 

MiCOM 

MMSA 

31  b80 

'  985 

b40 

2  0/ 

Mhs.. 

5v‘l 

M/AO 

1  215,4b' 

5  36/  9/5 

2  334  'h' 

3.940  01 

M/.M 

•I'i  18’ 

\-<vv 

286  93  3 

'2  12 

*4avv 

/M».  i  1  { 

UCMj 

4/b  889 

388,157 

220  535 

3  3 1  90 

NCAO 

1  -b  8M9 

18S  • 

N(.8 

304 

0  01 

N(,B 

s/ 

OTf  A 

10  300 

0  44 

OTF  A 

PijOA 

482.5  35 

390,9  72 

219  022 

332  81 

R'lOA 

182  35 

<9C  9 

RHAD 

1  2’8.94i 

5  356  h4S 

2  2  34  'h- 

3  939  18 

RRATi 

1.11  ’  8b 

i' 

SI  AO 

4H2  54S 

390  9/0 

2'9  .22 

3  32  81 

Sf  AO 

182  S-:S 

<<i-  9  •  • 

Sm..: 

Wb  889 

3HH  f 

13'  9 ' 

-.MAI  • 

1  4'i 

'Sh  '  ■ 

SSC 

iO-l 

)  )1 

SS( 

f  A(, 

2  ’0  'll') 

1  2 '8 

/Ob  ' 

'  'b  89 

At, 

’f  Al. 

1  /b9  rn 

3b0  1  ;  • 

/  1'  b  .  |S 

;  !.;•  8' 

'1  Al 

’  2 '2  '.in 

;  iH 

'f  COM 

24  125 

'2-1 

S... 

'  »b 

1|  COM 

■').  300 

1  1 

■•'Stnr 

•'iOS{  OM 

3  5i)0 

OM 

1  ■-.;o 

0  >« 

M  3 

r:  ’.29 

2'.  4'  '♦ 

•.  .-M  I  ' 

. '  • .  t 

a-.'.; 

,, 

Note  .  I  *r«'  n  .ri  K  Oi,  tl  D  isi*.  *  -w  >.  -  ..  j.  .j 


TABLE  C-39 


U.S.  ARMY  TEST  AND  EVALUATION  COMMAND  (TECOM) 


TECOM 

to 

Text 

E  nqmeefinq 
Or-^wl^a 

iHu^tr-ition 

Billion 

Dits 

TECOM 

trom 

'•^»t 

AMC 

AMD 

;s 

2 

AMCCOM 

AMCCOM 

'0  SSB 

-.SCOM 

AvSCOM 

(•:  i42 

■/  »» 

crcoM 

CECOM 

Jnrt 

C  -^nX'  v.t  -r 

C  -Ht'  »ft  .r 

PA 

2 

1 

)  Di 

C-A 

FORSCOM 

^5 

2 

1 

0  01 

FORSCOM 

s; 

LFA 

2 

1 

0  01 

i-EA 

MRDC 

NHDC 

s 

’Av.OM 

taCOM 

^-1  ■'2'^ 

TRADOC 

2 

1 

0  01 

TRADOC 

s 

’“•.t  •Kti'.'tv 

2 

1 

001 

tf*St  Kl'v.tv 

sc 

; 

"HOSCOM 

TROSCOM 

2b^ 

/Wofe.  Ail  nu'T'OArs  -jn  annual  O-ms  A  qihp.  <  i. ,  t>»‘ Of'- <d*'a 


TABLE  C-40 

TOBYHANNA  ARMY  DEPOT  (TOAD) 


'OAO 

»()AD 

ffv^m 

•.'.t 

I  f  jin.'uriM  ; 

Jf.lAi'l'l 

AMCCOM 

1  -194 

2  6*1  ’ 

/  8b  1 

9  24 

AMCCOM 

’•8  994 

M  (>.J  1 

TFCOM 

9/}.  168 

1  ;;s 

'18  T/l, 

■  ’8  90 

Cl  COM 

•  •.••)  9 '8 

•>  S-1-1  8/S 

c  DA 

C[>A 

1  i.'2  2‘)2 

.'•1  1  M 

r.itr  f)f.i 

'9/  0^0 

9  vH/ 

8  {4 

MU  OM 

•H*  S.’  ) 

■fs )  :m  < 

TACOM 

S4/  6M 

2']  S  )■) 

>2  i24 

'0  /o 

’ACOM 

h  i 

;  ) ''  19 

'  Af,  Al-’f 

Al'( 

H  U-,  •// 

1  : 

IMOSCOM 

'S;.M9 

■i22 

22  me 

'9  DO 

THOSCOM 

hii  9  -  9 

H9  // 

/Mof©’  '‘k'l  r'ljmrjr-fs  ♦f<’ '  >n  m  .»nPU'ii  h-i'i'S  -•  O' *p»  f'  r>»*  O*'  '0'’0 


(  lM 


^  V  vii 


V'. 


■f  ';^y*jj»A?Fini  V'V  L^''.V.V.VW'JVl 


TABLE  C-41 

TOOELE  ARMY  DEPOT  (TEAD) 


TEAD 

to 

^e»t 

fc  nqinpprinq 
dr.iwinq 

'lustration 

Btllion 

bits 

T£AO 

from 

|H 

il'ustr  <tiOn 

81 

OltS 

amccom 

A22.bS9 

S  1  /7 

98  '28 

7  7  00 

AMCCOM 

AJO  'S9 

80  1  ! ' 

98/28 

•09  Sv: 

CDA 

CDa 

S94,b80 

388. 'OS 

322 ,488 

390  90 

MICOM 

800.828 

V48S 

V2708 

9;  44 

MiCOM 

98S,j28 

'  9S2  48S 

7/C./08 

•  4  34  00 

MCOM 

'  2’2  bJB 

.U4  C3i 

i")’  :u 

4 1 ;  SO 

TACOM 

•  /b97’8 

S  ibO  -H- 

3::b  s  3s 

-•  30  '  SC 

TACi-APC 

TA(,  ».PC 

•  SAI’BS 

2  3  2  34 

2  32  n-'. 

9b  2  C 

TROSCOM 

2*0  94; 

!  VS 

•2  99  3 

4b  90 

TROSCOM 

2J2  '22 

84  9  7S 

-BS 

92  4J 

Nof:  All  numoer^  Ate  on  An  AnnuAt  b*^VJS  A  oMn*  ..^nnotps  lo  t>e  ae<i6ea 


TABLE  C-42 

U.S.  ARMY  TROOP  SUPPORT  COMMAND  (TROSCOM) 


innij  |i  t)  !•,,«, 


n*  !••  -i*  -I 


(■  _j 


TROSCOM 

to 

Tp*t 

Fnqinoprinq 

or^wino 

•llustr  »t'On 

Billon 

bits 

'ROSCOM 

IfC-m 

r  lA  «■  ; 

AMC 

4764 

142 

003 

AMC 

4  36S 

2  23 

AMSAA 

1.000 

St 

0  01 

AMSAA 

ANAO 

*tV378 

601 

50.688 

28  b' 

ANAO 

S4,378 

bOl 

so  688 

28  b' 

BRDC 

BROC 

17  380 

86  3S0 

4'  92S 

66  4' 

CECOM 

3.500 

0  'S 

CECOM 

: 's 

Contr4<tor 

900 

'SO 

300 

:  2/ 

C-.ntf  liter 

M)0 

'OO 

2JC 

■  '3 

OA 

30  4b4 

'  7  800 

2  ’n 

A  9’ 

(A 

'  7  280 

T  300 

2  '  b 

.1  ’ 

DESCOM 

S  1  9b9 

84  8S9 

'  3/8 

19  3' 

t-J  SCOM 

•S  /b8 

•'89 

►>i.i 

■  i  i 

f  USA 

'S 

f  ■  iS,. 

f -Plb  uSPr 

4  980 

.12' 

F  iV'r 

’  ilxi 

•  S(  {) 

FORSCOM 

9  bOO 

0  41 

FORSCOM 

22  :Hr, 

Si.'O 

2  »' 

Ft  MO'Xl 

80 

SI 

J  03 

Ft  M(  v,d 

Ft  l*»WtS 

80 

St 

0  03 

F  t  1  AW'S 

ft  RilPy 

80 

SI 

003 

Ft  RilPV 

LABCOM 

80 

St 

0  03 

U'.BCOM 

1  HA(> 

S  3  9  32 

\n 

S0.b88 

28  44 

1  HA[) 

V  t  )  </ 

i,-, 

».K*. 

1  FA 

t  900 

0  J4 

U  A 

IFAU 

9S  99S 

84,809 

S/  4S2 

/b9l 

1  y  At) 

84  BS 

•  S9 

■  3  /ii.' 

1 '  r 

1  fonfor 

80 

SI 

0  03 

l..,a  ont.'f 

MRS  A 

42  22; 

24  '00 

132 

14  34 

MHSA 

'8  947 

• Hco 

•vJ  ■.  t 

S4  242 

SB  i 

SO  t>88 

28  b' 

M.’AU 

S4  24/ 

3 

1.88 

S  1  9/b 

WJt) 

‘D  «iK8 

/K  la 

NCAI’ 

3  9  7». 

w  'O 

i.HH 

*v/  '■ 

' 

7M|il 

i)M  .. 

••  -Hi) 

<1  i.  '■'I,' 

*1 


TABLE  C-42 


U.S.  ARMY  TROOP  SUPPORT  COMMAND  (TROSCOM)  (Continued) 


E  noioporinq 
d^-tvwinq 

ilusiration 

Billion 

bits 

1 - 

TROSCOM 

from 

8/^ 

S0.b88 

28  71 

P'JDA 

db9 

SO  b88 

28  SI 

RRAO 

8.J  fn 

2b  S/2 

b4  20 

SAAD 

■31)0 

•%J  b88 

28  -14 

S'lAO; 

) 

^4COM 

84.9/^ 

V  ‘HS 

•12  14 

'1  AD 

)  2b 

TECOM 

84,772 

2b  S;2 

b4  21 

■OAD 

9  /O 

’RADOC 

ijSAHt  uR 

WtSTCOM 

1 1  .'H 

D'Ts 

:  b88 

2  8  ■’ 

tOoSB 

/8  SI 

22  me 

•9  ec 

;  -)Hh 

.8  -34 

}  ’  s 

■V  995 

tb  9  1 

22  380 

"?  G  1 

21b 

)  3  3 

2  ’b 

n  4  ! 

21b 

b41 

Note.  4ii  KP  00  DhS'S  A  bl-^ntt  •;Of'notPv  t  :  Oe  <3<=>< '00<J 


TABLE  C-43 

U.S.  ARMY  ENGINEER  SCHOOL  (USAES) 


TABLE  C-44 


U.S.  ARMY  EUROPE  (USAREUR) 


USAREUR 

to 

rp»t 

Enqin^prin^j 

qrawinq 

'iiustration 

Billion 

bits 

AMCCOM 

200 

001 

AVSCOM 

/.‘JOO 

1.975 

1  975 

2  36 

CECOM 

soo 

0  02 

MICOM 

■IQO 

0  02 

TACOM 

soo 

120 

120 

0  04 

TROSCOM 

17  280 

10.800 

2’b 

64  00 

AMCCOM 

AVSCOM 

CFCOM 

MiCOM 

taCOM 

TROSCOM 


Note:  All  number^  Are  on  ,in  annual  bdMS  A  blank  connotPs  to  be  oeoOeO 


TABLE  C-45 

U.S.  ARMY  INTELLIGENCE  CENTER  &  SCHOOL  (USAICS) 


'SAiCS 

bits 

‘rons 

001 

AMC 

AVSCOM 

001 

CAC 

lABCOM 

001 

TRAOOC 

0  05 

'RADOC 

sth<>/'s 

Note:  All  nomb<?''s  arn  vn  m  innu-nbiS'j  ..  D'an*  •  i'"- bn  gp,  icje<j 


TABLE  C-46 

UMATILLA  DEPOT  ACTIVITY  (UMDA) 


Rinvgiifvfivvmvvimnnvvwvv  wui  w-ww  w  w  v?  vwv»  wsw 


TABLE  C-47 

U.S.  ARMY  WESTERN  COMMAND  (WESTCOM) 


WtSTCOM 

|H 

— 

WfSTCOV 

j  fi  ] .  -y  • 

jsf  ♦’  r’ 

■i  - 

to 

■■■ 

IHI 

_ 

'ROSCOM 

17.280 

’•;  3C0 

7  ’n 

H 

’HOSCOP7I 

VofG.  “Il  Ouf^OPrs  .u**  on  -in  u  *'  D'^')lS  •*  D'  »’'•  ,nn-  ■*•»%  T  '•  D*'  3*’ 
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